It doesn't actually do that though. If you give a machine an IP of X, and then you turn on NAT on the upstream router so that its outbound connections appear to come from Y instead, the machine is still called X.

NAT won't prevent someone from sending a packet to X, and it won't cause the router to somehow drop the packet when it sees it either. That stuff is handled by firewalls, not by NAT.

On Linux at least, NAT isn't handled by routing, it's handled by a separate layer (the firewall layer, in fact). I think that's the obvious way of implementing NAT: you're not routing at all. On the public side you're not accepting any packets not addressed to you. On the private side you're converting all packets, so you're not doing normal packet forwarding.

When packets arrive on the public side, you have to translate addresses sent to the router to convert Y to X, so you might as well drop packets that aren't sent to a valid target. I'd expect you have to go out of your way to get NAT "wrong," possibly by trying to stuff the functionality on top of actual routing. Home routers generally don't need to do actual routing ever (and if they do, they're in a non-NAT mode) so it would be surprising for them to get this wrong.

It's handled by a separate layer, yes, but that doesn't mean that the routing layer magically disappears. It's still there, and in fact it's still required to forward every single packet that goes through the router. NAT is just simply an extra layer on top that sometimes changes the addresses in the src or dst fields of some packets.

Dropping packets not sent to a valid target is called firewalling. NAT doesn't decide what's valid and what isn't; all it does is detect packets which correlate to known connections and rewrite some of the headers on those packets.

Home routers, like all routers, do a lot of routing. They sit between two networks and they forward packets between them, which is pretty much the definition of a router. Having some header rewriting going on doesn't change that.