[Xposed General] Chainfire:
First off, keep in mind I have not actually looked into Xposed internals and thus I'm probably making some assumptions about how it works that may not be correct. I'm also not actually testing the cases you present, just commenting on them from memory, a full answer would require full testing. Hopefully the comments are still of some help.

First, everything that needs to be written semi-regularly, should move outside of /system. On future stock rooted firmwares (without kernel mods) writing to /system will probably only be possible through recovery. So aside from the Xposed core, I would suggest starting the move to /data based operation as soon as possible.

This might already not work anymore on recent AOSP-based firmwares.

I have not tried this specific case, but why would (5) be an issue using /data under zygote-based contexts?

On some devices maybe, but generally speaking: no. Changing policies will require flashing a custom kernel at least once. It currently seems that in many cases a modified initramfs will probably suffice, and the kernel will not need to be recompiled from source, but it's still a reflash.

I have already prototyped an automated system for this, in case SELinux policies are making the rooted future even more impossible than it is in AOSP already, but I'm not building it until we are closer to an Android release actually containing these SELinux enhancements, as this target is moving pretty fast.

That depends (on stuff and things!). It seems "u:object_r:app_data_file:s0" context can be made read/writable by most instances.

This specific piece of code is triggered by a kernel/OTA update with an updated embedded policy. While this isn't exactly a common occurance, it is common enough that you will have to take it into account and relabel as needed.

Be sure to set your context when testing. The context set (or not) when playing around with su is usually none (unlabeled, but depends on firmware) and access to unlabeled files will be removed completely in the future. You need to specifically set some context (I might change SuperSU to use a sane default context in the future, not sure yet).

I'd probably use something like /data/data/com.rovo89.xposed/modules or /config or so ...

Unfortunately, like SuperSU, Xposed has to deal with some very rare edge-cases, which may not make the socket/daemon combination viable. Not all sub-contexts of zygote can necessarily connect to sockets, even when the socket context is changed. Unless you provide multiple sockets with multiple contexts - this gets messy quickly. I would advise against the daemon/socket combination specifically.

Shared memory segments are bit fishy on Android in general, but could work. I'd be very afraid of them restricting these in the near future, though.

There is no easy fix-all solution to this for something like if you need to constantly pump data from one process to another (SuperSU actually employs various methods to do this, of which so far it seems that even in all the edge-cases I have tested always at least one works), but I think for Xposed configuration and low-volume data exchange, simply using files in a folder you watch may be the most practical answer (if that can be made to work), maybe with a daemon orchestrating it all.

Also please note that in many cases the subcontexts of zygote have more access than the zygote context itself. The system_server context seems to be the most powerful at the moment.