("1-NAT") When the incoming traffic is received, the NAT will only forward the traffic when the incoming traffic comes from an IP address that is part of what the NAT table provides. So the local public interface's IP address W on port Y has to be sent to dev0 on port X, but only if the traffic comes from remote public interface IP T port U. IP T port U were placed in the NAPT (Network Address Port Translation, a.k.a. PAT or NAT) table when the first outgoing TCP connection was made.
That piece of my answer is largely just hijacking what Daniel said in his answer, with (I hope) slightly more specifics for clarity. However, this explanation still leaves the possibility of a port conflict, as there doesn't seem to be a way for traffic from IP address T to public interface W port Y to make it to the DMZ.
Well, in addition to that approach
("1-NAT"), I hereby add two other methods,
("3-EPH"), that can help to prevent this problem you speak of.
As a quick summary of what you'll find, by my last paragraph here, is that statistically few people are likely to ever be affected by this potential issue. (Most routers sold for homes will be to people who don't run their own servers.) Those who run important servers will often not just forward all TCP ports, and so they will also not encounter an issue. Out of the smaller number of people who do have the potential to be affected, there are option that are technically available to those who really care enough to adjust configuration options.
("2-LSTN") First of all, if the router is set up with a port forwarding rule with public IP address W port Y, then that address is in use by TCP. There might not be an "ESTABLISHED" connection, but it will be "LISTENING" on the port. For comparison, try running "netstat -na" on Unix or Microsoft Windows, and you can see that traffic is "LISTENING" on
*.*.*.*:443 if an HTTPS port is being listened to). So a router probably would avoid sending traffic out port Y if it had that port forwarding rule for the DMZ.
This answer is kind of assuming that you're only sending select ports to a section of the network that is treated like a DMZ, and doing this via port forwarding. If you're just forwarding all TCP ports to the DMZ, which is the technique used by the "DMZ" option in some router configuration screens, then this obviously doesn't work because the router doesn't know about specific services that may be provided by the DMZ server. Fortunately, we have one more potential trick up our sleeve.
("3-EPH") The other thing is that helps with this is that outgoing port Y is typically selected from the list of possible ephemeral ports (perhaps also known as "dynamic ports"). Outgoing traffic typically uses a random number from the range of ephemeral port numbers. The range of ephemeral ports can vary: IANA suggests TCP port 49152 or higher (up through TCP's maximum of 65535), and this is used by Microsoft Windows Vista and newer, and FreeBSD 4.6 and newer. XP uses and BSD systems may use 1025 to 5000 according to Wikipedia's page on Ephemeral ports, or 1024 to 4999 according to NcFTP's page on Ephemeral ports (Microsoft Windows section). Linux may use 32768 to 61000. These values are customizable, as described in more detail on that NcFTP page that I hyperlinked to.
As long as a device is selecting an ephemeral port range that doesn't conflict with the services provided by the DMZ, then you won't have a port conflict.
Now, since most people don't tinker with the ephemeral port range of their router, then what is absolutely preventing the potential for a conflict?
As I see it, the answer is "nothing". However, the risk seems rather acceptable from a business standpoint (like the business that manufactured your router). Let's review this quickly. Your most critical services (like HTTP(S) and SSH) likely have port numbers in the "well-known" port range (0-1023), and so the router's ephemeral ports probably won't conflict
("1-NAT"). For other services, yes, there is the potential issue that outgoing traffic from the DMZ could result in NAT using up a port that you wanted the DMZ to be able to listen to. It would only affect the system that the outgoing traffic connected to (via NAT), and your chances are about 1 in 16,384 if the router is using the IANA-recommended range of Ephemeral ports
("3-EPH"). That's probably just viewed as an acceptable gamble for the statistically small number of people who use a DMZ for ports outside of the well-known (0-1023) port range, many of whom probably use it for an individual gaming session (which probably does not have major financial consequences worth suing over). If a gamer was affected, then voodoo magic (trying random things, like rebooting equipment) may very well result in the 1/16384 chance not occurring. For professional connections where this stuff matters, they have options like tinkering with (a.k.a. customizing) the values used for the ephemeral port range or, more commonly, using stricter firewall rules that only forward specific ports needed, which would likely cause the router to know to not use that port number