For others, the current direction is specified here: Shared memory in /dev/shm rewriting
A per-snap /dev/shm is an interesting idea, but I’m not sure that it will solve all cases (that would have to be investigated). Eg, suppose we bind mount /dev/shm/snap.snapname from the host onto /dev/shm in the guest, what happens with the problematic sem_open()?
Assuming that can be addressed, I suspect that simply the act of having a per-snap /dev/shm without the importing/exporting will solve many problems-- AIUI, it would be fairly unusual for an application to expose endpoints in /dev/shm for other unrelated applications to use (please correct me if I’m wrong). Therefore, simply making it per-snap is probably sufficient.