I believe this issue boils down to a couple of practical matters and one phylosophical one. The phylosophical one is this: How much commoditized should a peer (or for that matter - the instanciation of any group on a peer) be ? Let me explain. There is no notion of user at the core of JXTA. So a particular session, is not specifialy related to any user; although an application running into it could be related to a user. There is no real persistent state either, just a cache. The idea is that real persistent data should be distributed. So, if it does not realy matter on which peer you're running JXTA, does it realy matter if two "users" are using the same running instance of JXTA ? And if not, does it matter if two users authorized to use some group are running the same instance of that group ? Here I'd tend to say...it could; unlike the platform group, which behaviour we know, it all depends on the groups implementors. So, my personal conclusion - your's may differ and I'd like to hear about it - is that, in general, we cannot dictate that group instances are sharable; we have to support the case where two sessions dictate two instances. Then, weither we do not support sharing at all, and if yes, how, becomes a practical matter.
For the platform itself, I'm not sure, but I think, there too, the deciding factors are ultimately of a practical nature.
The number one practical issue about sharing the platform between unrelated sessions is that it basically means running it in separate processes. There would in fact be many other advantages in being able to do this. There is barely a hint of it in the current code with service interface objects. If we actualy (in some distant future) ended-up separating the interface from the implementation and put some sort of pipe between them, then we'd be able to run not only each group, but each application and each service in separate processes; may be in separate execution environments: java, shell, perl whatever. As someone pointed out, however, there's a radically different way to look at it, for roughly the same result. One could imagine that each service or application running in a separate process has its own incarnation of the group into which or for which it works, which in turn has its own incarnation of its parent group, and so on down to the platform. Then, each of these tiny instances of JXTA communicate via JXTA protocols the JXTA way. That's radical, I admit, but elegant. I am not sure it is any practical, though.
Keep in mind, however, that both approaches are still far away as far as the reference implentation goes, primarily because services as they are today have an actual method call interface; unlike applications, there is no assumption that they can be used via messaging...for that we'd have to make every single API object a reference to a remote thing: inputpipes, outputpipes, messages, etc, etc. A good thing, of course, and as I said, I deliberately left some room for that, but a big headache at this stage.
Now back to earth. For a while, we're stuck with one process per session. So what do we do about exclusive system resources, such as port-numbers ? One thing we could do, as soon as we know how to expire stale advertisements, is to dictate that such exclusive resources cannot be counted on. Then we're left with explicitly well-known locations, like rendez-vous and routers. I imagine that, like other servers, these could be the responsability of the system administrator, that is one that has authority over the complete set of exclusive resources on the machine, and that should be enough to support rendez-vous and routers. If we're content with that, then we do not have to manage the sharing of well-known port numbers in JXTA and we can spend time on something else.
Better alternatives out-there ?