You seem to believe that if a router’s port is forwarded, then it will “propagate unwanted traffic”. This does not occur. When BitComet starts, it exclusively registers its listen port with your winsock. (If it can’t do so, then it quits and dies.) While it is running, nothing else can register for that port - it will be refused by the winsock. After BitComet terminates, your winsock has nobody registered for that open port, so it discards any traffic received for that port. There is no effective difference to the net or your system, between blocking the traffic with a firewall on the one hand, and throwing it out because it’s bound to a port nothing is registered for, on the other. Nor does this latter situation somehow create additional traffic. Do you have some evidence or reasoning to suggest that it does, or why it would be important in the first place?
If this is of great concern to you and you still think something happens anyway, then I suggest that you also use the Windows built-in firewall and activate ICF in the BitComet options/preferences/whatever. This will open and close the listen port on the windows firewall, whether the router is responding properly to UPnP commands or not. That will not stop traffic aimed at that port, nothing will. That’s beyond your control. But inbound traffic for it will be blocked by the Windows firewall. Using two firewalls will double your management burden, but it will do what you want.
The situation with UPnP is that it appears to be unreliable, and the errors, if any, that it throws are inconsistent. If you use it at all, then you subject yourself to this behaviour. BitComet does not include functionality to stop on UPnP errors or failures. UPnP performance has never been consistent enough or reliable enough to make that tolerable. Yet that is all that BitComet could do in response to either failure or incomprehensible response. Consider:
If you left your machine running all night, thinking that a download would be finished in the morning but instead find a dialogue that BitComet has stopped all transfers seven hours ago because the router said something it didn’t understand, in response to a command, so should BitComet continue or stop? and has been sitting there waiting for a response from you all night. You’d be annoyed.
BitComet cannot babysit everybody else’s router. If there were some consistent and enforceable way to apply UPnP – some sort of certifying authority for its behaviour, that all routers had to conform to, perhaps UPnP would be more reliable. But as it is, it’s left up to each of the many router manufacturers how they’re going to implement UPnP and how consistent with each other they’re going to be about it.
You use UPnP at your own peril. If it works for you on your hardware, great. If it doesn’t, BitComet’s not responsible for that and can’t fix it or control it. So if you wish to affirmatively control the situation, then you should do it manually.
If there were an unambiguous UPnP standard (there isn’t) and a governing body (there isn’t) which propounded certification (no such thing) tests (no such thing) that a router had to pass in order to be certified (no such thing) as UPnP-compatible (ditto), and that board somehow had the power to say, “Billion, you router model XXyy, firmware revision 12.345 does not meet standards. You cannot sell that router as UPnP-certified.” and somehow enforce this, then perhaps the standard would mean something. Among many other things, you, the customer, would have to understand and care about UPnP certification, ask about and choose not to buy a router because it lacks that certification. This is unlikely to happen.
Without that economic incentive, consistency is unlikely to happen.