Yes.

4.1 says that occupant ids "SHOULD" be unique to that MUC room; that is, other rooms on the service "SHOULD NOT" use the same identifier for the same room.

This is highly problematic, since if a user is open about their identity in the (example) C++ room, they may inadvertantly reveal their identity in the (example) Java room, causing them huge embarrassment.

Why is this a SHOULD?

 

Modulo the perennial problem of confusing "anonymous" with "pseudonymous", yes. Perhaps understandably, the security issue above results from pseudonymity, rather than anonymity.

Also, I think a more pseudocode-ish suggestion for implementation might be useful, and that might also result in a simpler suggestion:

You have (roughly) HMAC(room_secret, bare_jid) - sensible, but you can get a more efficient mechanism if you do: HMAC(server_secret, bare_jid || NUL || room_jid) - the limitation here is that destroying and recreating the room with the same jid will use the same occupant ids; the advantage is that it needs only a new global variable to hold a single secret, which is trivial in config. If your programming language doesn't like string concatenation with NUL, just use "/" instead. This might also avoid the SHOULD; assuming that was predicating on data storage needs or something.

(Aside: it recommends HMAC with a suitably strong hash algorithm; astonishingly even MD5 is strong enough here - I wouldn't recommend changing the text, mind, but for those on this list, use whatever hash algorithm is easiest).