Minor: I also personally do not like to wrap allocate or provide the stat argument, and I prefer to just let the compiler generate an error message at runtime by default. I don’t have a copy right now to check if it was left in the final version or not.
Major: The main conceptual issue I have is that I do not like to use the OOP for numerical codes, I very much prefer the Fortran 95 “pure” procedural style. I do not like overriding operators either. I do like some of the additions in Fortran 2003 (such as newunit and [] for arrays and intent(out), allocatable) and 2008 and 2018, such as do concurrent (although I haven’t actually used it yet too much in production).
Summary: I like using Fortran features directly, not create custom wrappers.
This works very well for smaller codes, or structured grid codes, electronic structure codes, etc. It gets tough for arbitrary mesh multiphysics codes, and I have plenty of experience with those too. I think Milan was creating a “proxy” for such codes. Still, my approach is to only introduce OOP features as needed, when the alternative is more complex in practice. I always start with procedural style.
I don’t have time right now, but I have been toying with the idea to create examples / tutorials on exactly this topic, and compare OOP style versus direct style side by side and discuss pros and cons of each, from my perspective. The basic tutorial that I helped write here: Fortran Best Practices — Fortran90 1.0 documentation does not go into this particular topic too much. I have seen the same issues with C++ codes, people often tend to over-complicate things with abstractions, when many times using simple “pure procedure” style is much simpler in practice. This is best discussed on particular examples, I have several that I encountered in practice. I will like to get to it eventually and write it up, perhaps as blog posts, then we can discuss it, and if people agree, we can create official tutorials, showing both OOP and procedural style approach on examples with pros and cons of each.