Deprecating the FRAG field in SOCKS5 (RFC 1928) in light of RFC 8900

Hi all,
Since the AFT working group has long been concluded, I am not entirely sure which current WG is the most appropriate for this discussion. If there is a more suitable venue, please let me know.
I’ve been looking at the UDP ASSOCIATE implementation in SOCKS5 (RFC 1928) and its interaction with modern network path constraints. I’d like to propose that we formally deprecate the FRAG field in the SOCKS5 UDP header.
RFC 1928 Section 7 describes a mechanism for application-level fragmentation. While this might have seemed like a useful shim in 1996, it has become a liability in the current Internet environment, specifically regarding the guidelines in RFC 8900 (BCP 227).
The main issues as I see them:

  1.
SOCKS5 is often used for UDP traffic that lacks built-in recovery or MTU discovery. By requiring the proxy to maintain a reassembly queue and timer, we are forcing a stateless flow to become stateful at the proxy layer. This introduces head-of-line blocking and memory exhaustion risks that UDP applications specifically try to avoid.
  2.
As RFC 8900 points out, a significant percentage of network paths drop fragments. When a SOCKS5 client splits a large UDP packet into multiple SOCKS fragments, the probability of the entire datagram being lost increases exponentially. If the underlying application is "raw" UDP, there is often no mechanism to recover from this, leading to silent failures.
  3.
In practice, most modern SOCKS5 implementations (both clients and servers) simply hardcode FRAG to 0 or drop any non-zero FRAG packets to avoid the complexity and security risks of reassembly. The feature is effectively "dead" but remains a potential vector for resource exhaustion attacks.

Given that the current best practice (RFC 8085) is for UDP applications to handle their own MTU constraints or implement PLPMTUD (RFC 8899), there is no longer a valid reason for the SOCKS layer to perform fragmentation.
I propose we update the SOCKS5 guidance to specify that the FRAG field MUST be X'00' and that any other value SHOULD be treated as an error, with the packet being dropped.
Is there any interest in a small draft to formally deprecate this, or is there a specific use case I'm missing where SOCKS-level fragmentation is still considered essential?
Best regards,
D.J.Vance