Right on..
Funny, just last week I got into an argument with a VMS person defending Culter's RMS on a DEC mailing list.
Here at Intel in NH, many of the old DEC compiler guys still work in the building (and still hack on a FTN compiler to run codes on systems we are still creating). Since, I often eat lunch with them, I just did a little research on the fact from that compiler to verify what I thought I remembered.
So I had laughed that you mention that Culter's compiler could on certain cases support RMS. Please remember that it was C and that compiler that forced him to add stream I/O to VMS. As time went on, many ( ?most? ) VMS developers (including the FTN team) stopped using the RMS library and started to use stream since it was >>so<< much easier.
To dmr's credit at the time of stdio, record I/O was popular on "enterprise" class systems - ney mainframes of IBM and BUNCH companies. Which is why VMS's I/O system was record based - DEC wanted a piece of that action (and got it). The Multics family widely used the idea of a byte stream and not needing some sort of "facility" or "record" system to do the work; but at the time it was not clear which would "win."
So the fact that Dennis was trying to provide an interface that could work on those machines, is again not surprising. I wonder what things todays engineers will get crapped on because it was not clear at the time which way things would go.
Clem
BTW, I 100% agree that the inconsistency of the interfaces, return codes sins et al, certainly have damaged us. But then again, who knew? Other systems (like VMS) which were much more consistent, but were not as flexible or "open" died, while C, FORTRAN and UNIX live on.