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.