IPv4 deprecated [options]

Some of the Internet Protocol bits have turned History in last November, without making much noise, afaik. Long ago when I started working in the RUN team, I was impressed by the amount of options described in the IP and ICMP protocols. There was so much a loose source-routing combined with route-record options could do.
I was quite puzzled then to see how many active/programmable networks papers would claim “we propose the following shim layer header between TCP and IP because using an IP option …”. Yes, the protocol claims ‘options’ are available, and yet, packet carrying such options were already second-class citizen in 2001, receiving only slow-path forwarding. Nowadays, they’d likely be dropped altogether by some security/performance middlebox at some point before they could reach their destination.
Well… so is the Internet. At some point, bright ideas converted into RFCs need to be turned into transistors or line of code. At some point, someone will say “no way: we can’t afford the chip that will support any memory alignment for the TCP header. If it’s not appearing 20 bytes away from the start of Ethernet payload, we’ll dispatch the packet in a queue for software processing. Period.” And the person responsible for chip design will know that he might have to find another job if the future customers think the forwarding rate is lame.
So between things that couldn’t be made efficient, those that were supplanted by wider protocols (DHCP vs. ICMP Information Reply (Type 16)) and those that never actually made it to the Internet (IPv6 Where-Are-You (Type 33)), possibly due to potential security issues (Domain Name Reply (Type 38)), https://tools.ietf.org/html/rfc6918 does not really surprise me, although it’s a bit disappointing to see hours of agreement process turned into “not widely deployed” with no apparent effort to explain why features didn’t took up.
The companion “deprecated IPv4 options” RFC mostly mentions things that were introduced to support experimental side-kick protocols, related to multicast, quality of service, etc.