A feature that lets you have Nagle running, but kick out the data in the buffer immediately.
Nagle does "kick out" the first packet immediately; it's subsequent packets that have a delay.
There are "interesting" interactions with "delayed ack." :-(
Nagel and Delay Ack were both algorithms aimed at the inherent inefficiency of small-packet traffic (ie telnet), back when that was a major application on the net. 160+ bytes sent on the network for each character typed and echoed was ... undesirable.
By now, no one much cares about interactive small-packet traffic :-(
And I figure that the "slow start" and other modern "congestion-avoidance" algorithms pretty much devolve to Nagle-like behavior when you're not sending full packets, which is fine for bulk data, but not so much for the small-packet traffic.
I know of at least one TCP implementation that implemented a limit on the number of TCP packets in the retransmission queue (5 packets, IIRC.) This had an effect similar to Nagle, only ... later. I'd be a bit surprised if microcontroller TCP implementations don't do something similar. (OTOH, the retransmission queue is theoretically bytes rather than packets, and maybe modern implementation are better at treating it that way. I have not kept track, and I'm afraid to do so :-( )
Examples [of "unfinished" TCP features] are the use of "PUSH" flags on TCP segments. Nobody agrees on what they should do and most routers remove them.
PSH and URG are pretty ambiguous (a bit of change of philosophy in how the OS communicates with the network layers, I guess), but I don't think that any
routers will change that level of of a packet...
(Serial Servers, OTOH, are likely to ignore and either never set or always set PSH.) (URG was used by the "flush output" feature of TELNET. Usually incorrectly and/or to little effect.