Thankfully, IPV6 can help mitigate this problem by extending the fragment id length from 16 to 32 bits. This gets you up to roughly 1.18 trillion bytes of 'safe' NFS traffic/second. There's plenty of reasons why IPv6 adoption is still fragmentary, but if you're running a high throughput network, this is certainly a motivator to move at least part of it to IPv6.
Somehow I always felt using UDP as a basis for a file access protocol had more potential. You shouldn't care about packets arriving in the correct order, only that the (likely, concurrent) read/write operations are completed. If I request a 1MB read, I don't need it to come in 1500b sequential chunks, I can wait for the read call to return me a full 1MB buffer.
It could also enable better throughput on high-latency (but otherwise speedy) links, like moving files between datacenters across the pond.
As far as packet loss is concerned, TCP is more robust, and is the default on Linux starting with NFSv3.
When using NFSv4, rpc.portmap is not necessary, so it cannot "go out of lockstep with the kernel" because it is not running.
As far as "foolish misconfiguration," solving a problem between the keyboard and the chair is not in the current features. Maybe the next release.
p.s. NFS over UDP can cause silent corruption over gigabit ethernet - see "man 5 nfs" for details (search for "Using NFS over UDP on high-speed links"). This is one reason why TCP is the default.