Here's my take on it.
The question on either or not it is even worth the committee's time is a fair observation regarding how trivial the feature is.
It's so trivial in fact that every single company that I worked had a version of it, they didn't bother to grab an existing library to do it, they just did it themselves, independently, over and over again, albeit
with different levels of sophistication.
It’s a task I would be more than comfortable to give to a junior hiree, and expect them to successfully complete it in a day.
But one thing they all had in common is that they were not ranges or views.
I think that using a range is about the most inefficient way of doing this that I can think of.
The best way to solve this problem is to just write the data from the source that has the questionable endianness onto a buffer, and then directly do the endianness correction in place and forget about the fact
that the source had it the wrong way around.
That is it!
I would be extremely surprised if you are able to find a popular piece of code that is actively used in which this isn't the case.
Just because you can write it as a range it doesn't mean you should.
Don't get me wrong the original concept of ranges was good, but I'm afraid that what it is evolving into is not, and nobody is questioning this.
Because it is easy to use and looks short on text, it is easy to forget how many layers have been piled on, and how convoluted the code path actually is.
It has just become a pile of slopy and apathetic code, and people don’t realize how much simpler it would have been and how much more efficient it would have been had you not done things this way.
That is my opinion.