Ultimately, my argument is that I want to set autojoin to false and for it to remain false, and not to be changed when I happen to join a room; obviously when it's now used in place of 'joined', that's unavoidable. But then, I never want to autojoin a room, so arguably that should be a client setting and the attribute is useless to me too.

I think you are a bit late to the party there.

Since years in Gajim, we don't expose the user to protocol details of bookmarks. We removed all mentions of bookmarks. No user does need to know the protocol details how a client syncs known chats. Why would a user need to learn what "autojoining a MUC" means when using Gajim.

I think your fear that this language change in the XEP makes your usage impossible is overblown.

What the XEP describes for me is a fair, common sense implementation, in absence of any advanced settings that your client may offer.

I think all your wishes can be implemented by a client who offers more control for that, call it "advanced multi device muc join settings".

Is this discussion maybe just a different opinion on what "SHOULD" entails?
When i read the RFC keyword definition, it seems ok for me that a developer offers settings that ignore this SHOULD.

I think there are valid use cases for ignoring the autojoin flag, or storing join information locally instead of syncing it to pubsub etc. and this SHOULD would not stop me implementing settings to satisfy such use cases.

Regards

Philipp