Meta bug for edge cases that should be considered to make room upgrades transparent

• Room membership (for public rooms) matrix-org/matrix-spec#455
• Room membership (for private rooms) matrix-org/matrix-spec#455 (and matrix-org/matrix-spec#425)
• Telling users about the new room if we are not yet syncing room membership (#1930)
• Arbitrary room state matrix-org/matrix-spec#454, matrix-org/matrix-spec#427
  • it's unclear whether it's sufficient for the upgrading user to be able to re-create the state on behalf of the original users, or if we should get the original servers to re-create the state. Presumably if we did the latter, then we could solve matrix-org/matrix-spec#455 too?
• Specific room state? (If we're not supporting arbitrary room state)
  • What flair is enabled for a room
  • What widgets are provisioned in a room https://github.com/matrix-org/synapse/issues/4994
  • Power levels
    • Bans https://github.com/matrix-org/synapse/pull/4642
  • Federatability https://github.com/matrix-org/synapse/pull/4530
  • Server ACLs https://github.com/matrix-org/synapse/pull/4642
  • Encryption https://github.com/matrix-org/synapse/pull/4411
• Tag state https://github.com/matrix-org/synapse/pull/4412
• Room directory entries https://github.com/matrix-org/synapse/issues/4948
• Per-room push rules https://github.com/matrix-org/synapse/pull/4838
• Community membership (i.e. which rooms exist in a given community) https://github.com/matrix-org/synapse/issues/4897
• Making bridges and bots and integrations in general upgrade-aware (e.g. https://github.com/matrix-org/matrix-appservice-bridge/pull/100)

At the least, we should ensure the spec reminds implementors to handle all these edge cases...

Review the unresolved Matrix spec issues #455, #425, #454, and #427, along with the remaining checklist item for widgets in Synapse issue #4994. Determine which room-upgrade edge cases still need a protocol decision, then update the specification so implementors have explicit guidance and the checklist is resolved.