The "old" version didn't have a test for the feature... the "new" version started with the tests for the "old" version... it was an easy thing to miss as a result.
As other threads have mentioned, a more advanced argument parser and detection of parsed, but unused arguments could have caught this. Of course, there's already complaints about the increase in size for the Rust versions of uutils, mostly offset by a merged binary with separate symlinks. It's a mixed bag.
But, I'm sure you'll be reverting back to Xfree86 now.
How can you be sure that something is "backwards compatible"?
By running tests. And as it happens, the original coreutils did not have a test for this particular edge case.
Now that a divergence of behavior has been observed, all parties -- the coreutils devs and the uutils devs -- have agreed that this is an unacceptable regression and created new test cases to prevent the same misbehavior from happening again.
A lot of database companies go to great lengths to be bug-for-bug compatible with postures. This does happen. It takes some effort, though, which does not appear to have been applied in the case of this rewrite.
Backwards compatible means it's a drop-in replacement.
> How can you be sure that something is "backwards compatible"?
You compare the outputs from the same inputs.
> the original coreutils did not have a test for this particular edge case
So? 'man date' shows this argument option. Just because there was no existing unit test for it doesn't mean it's ok to break it. It would have taken literally 10 seconds to compare the outputs from the old and new program.
As other threads have mentioned, a more advanced argument parser and detection of parsed, but unused arguments could have caught this. Of course, there's already complaints about the increase in size for the Rust versions of uutils, mostly offset by a merged binary with separate symlinks. It's a mixed bag.
But, I'm sure you'll be reverting back to Xfree86 now.