Sorry but I don’t get your point. I absolutely understand and relate to the fact you have some libraries with procedures that you would like to be all labeled as PURE. And I hinted at earlier, I can also see that you, as both a library author and someone who is also a consumer, find it convenient to work with polymorphic actual arguments - some of your tests with above libraries even show that. But these are not compelling use cases in any way in the Fortran world, particularly from everything-is-a-cost, have limited-budget / limited-resources, therefore need-to-focus-on-performance-features-only, that’s-only-what-Fortran-is-all-about mindset.
The kind of libraries you list above are of interest in the so-called preprocessing / postprocessing phase, before and after the number-crunching. This is the space that the compiler vendors, either explicitly with throw-it-in-the-user’s-face attitude or subtly, will argue (i.e., depending on which user(s) is asking and how they they ask - a la “no soup for you” ), is better done using means other than Fortran. The need for PURE procedures in such libraries is nice but not must-have. The need for polymorphic received arguments with INTENT(OUT) / INTENT(INOUT) attributes (thus ALLOCATABLE) in PURE procedures in such situations is even less compelling,