If you're natted, the source port seen by supernode doesn't have to be the same as the one seen by others. Someone on your network may be talking to the same supernode already, so the conflict has to be resolved by some remapping in the nat.
No. I don't know why you're not listening to what he's saying. I can tell you, from currently writing code that does STUN negotiation, unless you have two peers behind full-cone NAT (which is rather rare actually), you do not need to know what the port mapping/translation is.
I have a sideband connection to a server, and I tell it to route my negotiation packets to my peer's sideband connection. I literally never even touch a UDP port or connection, and the library I uses establishes a connection using STUN(-light). And from having read the source, it doesn't explicitly determine or set the mapping (using uPNP) either.
In my work with VoIP that situation was pretty much the default assumption. I agree that it's only the double NATed situation that's hard to handle, but stay by my opinion that sometimes it's just impossible to resolve without a middle man. But it depends on many things - clients, routes, number of people in local network using the same application, etc. Sometimes you just have to fall back to proxying everything.