For example, the dd problem that prompted all this noise is that uutils was enforcing the full block parameter in slow pipe writes while GNU was not.

So, now uutils matches GNU and the “bug” is gone.

No, the issue was a genuine bug:

The fullblock option is an input flag (iflag=fullblock) to ensure that dd will always read a full block’s worth of data before writing it. Its absence means that dd only performs count reads and hence might read less than blocksize x count worth of data. That is according to the documentation for every other implementation I could find, with uutils currently lacking documentation, and there is nothing to suggest that dd might not write the data that it did read without fullblock.

Until recently it was also an extension to the POSIX standard, with none of tools that I am aware of behaving like uutils, but as of POSIX.1-2024 standard the option is described as follows (source):

iflags=fullblock
Perform as many reads as required to reach the full input block size or end of file, rather than acting on partial reads. If this operand is in effect, then the count= operand refers to the number of full input blocks rather than reads. The behavior is unspecified if iflags=fullblock is requested alongside the sync, block, or unblock conversions.

I can also not conceive of a situation in which you would want a program like dd to silent drop data in the middle of a stream, certainly not as the default behavior, so conditioning writes on this flag didn’t make any sense in the first place