Spec leaves wiggle room in the rules surrounding `m.room.create` events

**Link to problem area**: https://spec.matrix.org/v1.2/rooms/v9/#authorization-rules

**Issue**

The auth rules begin:

> 1. If type is m.room.create:
> 1. If it has any previous events, reject.
> 2. If the domain of the room_id does not match the domain of the sender, reject.
> 3. If content.room_version is present and is not a recognised version, reject.
> 4. If content has no creator field, reject.
> 5. Otherwise, allow.

I understand this to mean that `m.room.create` events:
- MUST NOT have any `prev_events`.
- (implicitly) MUST have a `sender`, a `room_id` and a `content` field, each with appropriate types.
- this is vaguely guaranteed by the S-S API's [checks on PDUs](https://spec.matrix.org/v1.2/server-server-api/#checks-performed-on-receipt-of-a-pdu), which asserts that each incoming event "is a valid event". (See also #365.)
- This presumably means that it compiles to the PDU format of the given room version, and additionally complies to the room-agnostic specification of [`m.room.create`'s content, defined in the C-S API spec](https://spec.matrix.org/v1.2/client-server-api/#mroomcreate).
- (implicitly): MUST have a `room_id` and `sender` which are matrix IDs.
- Again, arguably covered by "the event is valid".
- MUST have matching domains for the `room_id` and `sender`.
- MUST have a `content.room_version` field which represents a recognised room version.
- MUST have a `content.creator` field.

I can see the following holes and problems n this definition.

1. There is no requirement that `content.creator` is an MXID, nor that its domain matches that of the `room_id` or `sender`. Come to think of it, why is the `content.creator` required at all, when the event already contains a `sender`? Should servers consider the event invalid if the creator and sender disagree?
2. This doesn't mention `auth_events` at all. Should servers ignore any auth events on `m.room.create`, or reject such events?
- I don't think it makes sense to include any auth_events here at all. Maybe you could make an argument for room upgrades, but there's a "Previous Room" field for that in the event's content.
3. Suppose `@alice:server` creates a room `!room:server`. What is there to stop `@bob:server` from trying to create a new room with the same ID?
- If so, how should homeservers processing these two events decide who wins? (`origin_server_ts`, tiebreaking lexicographically on the creator's MXID?)
- The client-server API is supposed to forbid this with `M_ROOM_IN_USE`, but a buggy or malicious homeserver could send whatever PDUs it likes.

Additionally:

1. A cross-reference to the definition of `m.room.create` would be useful here (though note my confusion and complaints in #1046).

Start with the linked v1.2 rooms v9 authorization-rules section, then compare its PDU checks with the Server-Server API and the Client-Server API definition of m.room.create. Review related issues #365 and #1046 and the comment discussion; done means the open questions have an agreed normative resolution and the requested cross-reference is addressed.

Written by the indexing model from the issue text.