Binary (or text) protocols needs to be de-bundled from transport layer for _a lot_ of reasons (looking at you QUIC).
Once we conquer this, we can de-bundle port number from service location.
In the early internet years, fixed ports were the service locator. Yet this has not evolved.
As another commentor said, you can now only run one instance of a service per IP, which is aburdly wasteful of the possible ~65k inbound ports. TLS and SNI have come up with workarounds, but the root problem is still, port numbers should be available for anything, and we should have a system for service location. DNS is certainly an option, but there are other practical ways to do it.
Then you could have one DNS entry per service. That would have been perfect for residential IPv6 with dynamic prefixes, which require dynamic DNS anyway.
But I guess one could always just bake it into the DNS record, so perhaps not a big issue in practice.
What is being wasted? It's not as if those extra ports have additional bandwidth or processing power available to them that you wouldn't otherwise have. You also need a spare port if you're going to do any outbound connections.
Worst case, as far as I can see, is that CGNAT providers might require more outbound IP addresses than they might ideally need if more ports were actually used; but in the general case, there is no reason to care about "wasted" ports.
how wonderful a world-wide adoption of rfc 6186 would be to able to put multi-domain mail server on a single IP.
HTTP and SMTP have their own ad-hoc, partial solutions to this (vhosting, MX records), but most every other service requires a unique IP address per instance.
With IPv6 this consideration is almost completely moot.
> MX records
Have fun with your MX not being port 25.
> but most every other service requires a unique IP address per instance.
This constant engineering overhead to play to the weaknesses of IPv4 is the problem.
why? it would be a great spam filter!