Deprecation of System.OsString in `1.4.200.1`

[sol]

At the risk that this will turn into a rant...

When migrating form GHC 9.8.1 to 9.8.2 I'm confronted with:

Deprecated: Use System.OsString from os-string >= 2.0.0 package instead. This module will be removed in filepath >= 1.5.

So yeah, moving stuff into separate packages can make sense. But wait, why doesn't filepath just, re-expose that module from os-string? Probably because they wanted to add the deprecation message? But this means that we will end up with clashing module names, uhhh... whatever, do I really care? Just use PackageImports and be done with it... oh, wait, WHAAAAAT, filepath does not even depend on os-path???

So what exactly am I going to do with this deprecation warning, except for ignoring it?

And how useful is a deprecation warning that provides a "course of action" that will result in compilation errors in all but the most exotic cases. How useful is a deprecation warning that you can only ignore, where there is no sensible action to take?

So what I'm going to do is add a OPTIONS_GHC to every affected module, to ignore the warning. This is mostly harmless, except for that it maps any other deprecation warnings, deprecation warnings that may provide actual value... and then, down the road, when I transition to a newer version of GHC / filepath I'll have to remember to remove those OPTIONS_GHCs again...

Sounds like a lot of wasted effort to me... for what?