There's path MTU blackhole detection. See RFC 4821. This or similar systems are enabled in most mainstream operating systems (but not Android, because Google would rather replace TCP with TCP over UDP than fix TCP with existing fixes).
Like cesarb's sibling comment, I think router driven packet truncation would be useful. IP fragmentation is generally problematic and router driven fragmentation was eliminated from IPv6, but truncation with in-band indication would work a lot better. For TCP, the kernel on the receiver of a truncated packet could send an in-band ack of the received bytes, with a tcp option indicating the effective MTU.
For UDP, it would be a bit more complicated, you would need to alter the recvmsg syscall to provide both the original size and the received size, and transmitting that information back to the sender would be protocol specific of course. The sender would then either trigger IP fragmentation to appropriate sizes or some protocol specific fragmentation.
In my opinion (with hindsight), the IPv4/IPv6 model of "drop packets which exceed MTU" as the alternative to fragmenting packets was a bad choice. It would have been much better to take a third option and truncate the oversized packet. That would avoid both the bad effects of fragmentation (slow path in the routers, memory use in the receivers, non-initial fragments which lack the higher level headers making it a pain for firewalls) and the bad effects of dropping (waste of the bandwidth to send the dropped packet, broken firewalls discarding the ICMP message, CPU use in the router to send the ICMP message).
Except in practice this is useless because you're now transmitting what is basically a corrupted packet.
For this to work, L4 protocols would need to be completely redone to consider and work with this concept.
Also, what is actually meant to happen is that an ICMP(v6) packet too big message is supposed to be sent back to inform the sender that they need to reduce the packet size.
Unfortunately, with the pervasiveness of idiotic firewall configurations that blanket block ICMP, this falls apart which is why we have to deal with ugly hacks like TCP MSS mangling.
Like cesarb's sibling comment, I think router driven packet truncation would be useful. IP fragmentation is generally problematic and router driven fragmentation was eliminated from IPv6, but truncation with in-band indication would work a lot better. For TCP, the kernel on the receiver of a truncated packet could send an in-band ack of the received bytes, with a tcp option indicating the effective MTU.
For UDP, it would be a bit more complicated, you would need to alter the recvmsg syscall to provide both the original size and the received size, and transmitting that information back to the sender would be protocol specific of course. The sender would then either trigger IP fragmentation to appropriate sizes or some protocol specific fragmentation.