I just can't agree with your assumption - you still try to say that there is something wrong with the library/object system on this platform. I don't see that it is. Your new assertion doesn't really change things much.
I guess I find the library system to be very useful and don't need a multi-level file system to do my work. It IS a database system, after all, and other replies that mention the single-level structure seem to apply here. Analogies abound - programs and stored procedures are functionally equivalent, seems to me.
You asked first about separate environments. We can effect that pretty easily with LPARs or IASPs or library lists or change management packages, etc.
I'm thinking about SQL Server - we have separate machines here for stage and production, I believe. That would be like using LPARs. But you can just as easily install separate instances with different credentials. That could be like having different libraries and different user profiles.
Seems that for database development and for apps that use a database - this is what we mostly work on - that the SQL Server structure is very much like our library/object structure.
So, again, I don't see that the library/object FS has any limitations that matter. To say that "...competitive OS's improved upon..." them seems to be an apples and oranges thing. And maybe looking at the wrong side of things - or at least an unimportant or unhelpful aspect.
----- Original Message -----
OK maybe people have thin-skin this week because of the labor day holiday. Or maybe antiquated is the wrong word. I will substitute that word for "a major design element that all competitive OS's improved upon in the 1970's except for OS400". (Maybe the 1960s)