Hi,
I think all of these discussions are merely caused by wording of the
attribute. For historical reasons, it's called `autojoin`, but what we
nowadays want to say with it (or how most clients want it to be used)
is `joined`. Maybe we want to add a note to the XEP that explains this?
The concept of joining a MUC in XMPP does not reflect how people use
messaging these days. I think this is widely understood and is for
example also included in the design of MIX.
Barely any other messaging protocol requires clients to join every room
the user wants to be part of every time they connect. IRC is one
notable exception and we all also know that most IRC users use bouncers
to bypass this and other protocol restrictions.
When it comes to UX, I would assume most people nowadays assume that
leaving a room using their account on one device also means they would
leave on other devices with the same account. Similarly, people also
assume that if they are joined in a room now, they would still be
joined if their client needed to reconnect (due to a network outage or
them switching from one cell tower to another).
And finally, I think it's perfectly fine to say in a XEP "when a client
receives message X, it SHOULD leave the room", even if that affects UX.
In fact, there are other messages already that have a very similar
effect on the UX, e.g. the user being kicked from a room. How the
client displays that they were kicked or left on another device is
entirely up to the client, but what remains is that it should no longer
be considered a member of the room. If a client developer wants to,
they can ignore both (not leave when autojoin is set to false or
immediately rejoin after being kicked), but it's certainly a bad idea.
In fact it's so much and obviously a bad idea, that nobody even
bothered to add a note to 0045 that clients SHOULD NOT automatically
attempt to rejoin after being kicked.
Marvin