Hi Sean,
My feedback as follows:
1. I like the ephemeral approach to handling data, and view this as a near necessity for any interwallet communication scheme.
2. Payjoin v2 makes the specific tradeoff of privacy over performance, favouring OHTTP and HTTP polling to protect user IPs. Your approach using websockets does not protect from the relay learning the IP addresses of the participants. The draft says "This ID allows participants to distinguish between different connections/sessions in the room and audit log without the relay or other peers learning the user's IP address or permanent identity" - but in fact the relay does learn the user's IP address. On this point I lean towards privacy over performance, as I don't think real time response is needed here. Apart from protecting users, a privacy preserving approach also lowers the risk of running a relay.
3. The proposal focuses only on multisig PSBT sharing, but there are other interwallet communication use cases such as multisig setup and payment confirmations. In my opinion, addressing the challenge of interwallet messaging should be done as a series of BIPs to specify the transport separately from specific message protocols for various use cases. This allows for future extensibility by making each layer independently reviewable and upgradeable.
4. This proposal still relies on out-of-band sharing. The BIP draft specifically notes that out-of-band PSBT sharing is "heavy operational friction" but still requires out-of-band sharing for the room setup - which is essentially equivalent in complexity. In the case of multisig wallets, there is already private shared state in the multisig wallet setup, and in most cases the wallet client is already connected to a server of some kind. It seems to me that as it stands, this proposal will be replaced by one in future that takes advantage of these facts simply by virtue of being a more convenient user experience.
Craig