Someone correct me if I'm wrong, but I think p2p-webtransport was superseded by "webtransport" (https://github.com/w3c/webtransport). Supposedly, the webtransport design should be flexible enough to support p2p even though focus is the traditional server<>client.

The story here is a bit complicated. WebTransport is, in some sense, an evolution of RTCQuicTransport API, which was originally meant to solve the issues people had with SCTP/DTLS stack used by RTCDataChannel. At some point, the focus switched to client-server use cases, with an agreement that we can come back to the P2P scenario after we solve the client-server one.

Superceded? No. Webtransport already was well on its way to approval when p2p-webtransport was created.

Webtransport as a protocol certainly could be used for p2p, but the browser APIs aren't there: hence p2p-webtransport was created, to allow its use beyond traditional server<->client.