I'd like to point out that your new ProtoXEP PR is not exactly only the extraction of the previous proposals addressing and occupancy portion, it does include new parts that the previous proposal lacked. Notably it does introduce some new wire protocol parts (specifically the <part/> element). The fact that you created (or had an LLM create) an implementation of what is currently described doesn't really change anything with regards to if it can be implemented, if that implementation is simply useless in practice. As I had also written on GitHub, your new proposal still completely ignores addressing on messages (you know, the thing we primarily use MUCs for), which still has problems unsolved in practice. I don't know Openfire well, but from what I understood, the implementation will simply keep messages for muc2 occupants as is, meaning they still have the nickname in the resource and occupant-id in the message payload.
I think it's fairly obvious that if addressing of occupants changes, then the addressing of messages as well as presence changes. The addressing of iq stanzas will also change. If the implementation is wrong on that front, then the implementation is wrong. Again, implementation isn't required for Experimental (or even Stable!), according to XEP-0001.
I have absolutely no doubt that the ProtoXEP is not at the quality gate we'd require for Stable, but I would like to actually bring it into the XSF and work on it with the rest of the participants in this SIG, under the XSF's IPR policy.
Beside that I disagree that those two things, addressing and occupancy, are closely interlinked. The whole bare jid occupancy session part as described works equally fine with the old addressing scheme. From what I understand, the main thing that's different with the new addressing scheme is where nickname and where occupant id are to be found in the stanzas.
I think bare jid occupancy is sufficiently embedded into the concept that it's hard to remove, or at least hard to add in cleanly later. It doesn't work "equally fine" with XEP-0045, which is why there's a bunch of compatibility requirements around that exact case (ones you've commented about on the PR).
As MattJ has noted, XEP-0045's increasingly patchwork nature is problematic, and I was hoping not to replicate that.
Dave.