I don't have a solid opinion on this. Coreutils 9.3 was pushed to Rawhide 5 months ago. The change in 9.3 might break some automation for someone, but at the same time, the revert in 9.4 might also break some automation for someone. It is hard to judge for me whether we want this pushed through the freeze or not. If not considering automation (especially releng automation), on an end-user level, I don't think this is justified for a freeze exception. Overall I guess I'm leaning a bit towards -1.

Consider that for regular users (people running release versions... not Rawhide) the verbosity change is so far unseen, because only Rawhide got the change. So for regular users, the automation breakage will come with the 39 beta. For me it came in Rawhide. By pushing this through regular users are spared the pain. In any case, with the 9.4 backported patch now in 9.3 it means the revert is going to happen anyway in 39 as soon as they update. Why glitch their experience with the beta?

Yes, but the behavior will be back to prior versions the first time they install updates on Beta. So the timeframe when they see excess cp messages is minimal. And I see the extra messages as a mostly cosmetic thing. That doesn't feel important enough to break the freeze (and risk some regression). See the policy here:
https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process

AGREED AcceptedBetaFreezeException

Discussed during the 2023-09-04 blocker review meeting [1]:

the benefit here isn't huge (getting the new/old behaviour during live sessions and at first boot, not just on first update) but the risk is also small and we're feeling generous, so...fine.

[1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2023-09-04/f39-blocker-review.2023-09-04-16.00.log.txt

The following votes have been closed:

• Accepted BetaFreezeException (+0, 0, -0)

Release F39 is no longer tracked by BlockerBugs, closing this ticket.