On BlameOf / the tree attack: The "no new inputs in a blame round" check helps, but it doesn't close it. The coordinator doesn't add inputs, it splits the honest set into per-victim subsets (each passes a subset check) and re-keys each branch, and the "original round" is just whatever it showed you anyway. Hashing BlameOf plus polling over separate circuits is what catches it; and only a signed commitment makes it provable.

Maybe I'm misunderstanding, but I think the BlameOf commitment is for preventing the coordinator from covertly merging tagged rounds:

• Alice, Bob, and Charlie open satoshi connections to the coordinator to listen for round updates
• The malicious coordinator feeds each connection different round IDs
• Alice registers to fake round A, Bob registers to fake round B, Charlies registers to fake round C, and the coordinator inserts enough faked inputs in each round to trigger the signing phase
• The coordinator fails rounds A, B, and C, then creates legitimate round D
• Alice, Bob, and Charlie's tagged coins all join round D (since it does not commit to any specific A, B or C round)
• Round D succeeds: Alice, Bob, and Charlie's outputs gain anonymity score, but the coordinator knows the links between their inputs

This would be prevented by the "no new inputs" check since the participants in round D would recognize that multiple blame rounds are being merged together. It would also be detected by a cautious user that checks the publicly posted round ID.

Is there a different attack you have in mind?

The nuance I'd keep: a public feed only leaks round metadata, not the input to output map

The input to output map should be fixed by increasing the gap limit, but this was NACKed by the maintainer in favor of deriving coinjoin outputs via silent payments. I don't know any details on how this would be implemented.

But (1) the coordinator can just Sybil with its own real coins

WabiSabi is uniquely resilient against Sybil attacks. Users choose their own rounds, the coordinator does not choose rounds for users:

Users can submit multiple inputs, which would allow them to detect if any specific input is being targeted.

This means a malicious coordinator would need to have 100x more liquidity and pay 100x more mining fees compared to the target, while the target (and every non-target participant who gets rejected) is able to detect this attack. This 100x cost is a lower bound, since a convincing Sybil attack would also require extra idle liquidity and pay fees in previous/future txs.

(2) with fake inputs the link is already recovered at output registration, before signing, then it aborts, so no tx is ever broadcast. That would be enough for an evil coordinator to link inputs together or know what payment you were trying to do (amount and destination).

I'm not sure what the solution to this is, maybe some sort of sanity check on the maximum number of concurrent rounds? There was a coordinator that tried to fabricate activity: https://bitcointalk.org/index.php?topic=5498650.msg66122296#msg66122296