I've been reading a lot about Niklaus Wirth recently. I read an interesting piece about Oberon I found in an HN archive[0] that mentions Oberon usage on Macs. I'm very tempted to buy "The School of Niklaus Wirth: The Art of Simplicity" after reading a few things about him. I wish there were more instances of "computing in a vacuum" like at ETH.
I studied under Wirth at ETH Zurich in the 1980s, so I got to interact with him personally a number of times. His class on compiler construction was particularly interesting. You could see how a philosophy of simplicity and clarity in syntax and semantics would translate to simple and clear compilers.
The downside of this philosophy was that aspects of interacting with a computer that were inherently messy tended to be swept under the rug: The original "file" and "string" concepts as described in early Pascal reports were simply unworkable, and combined with a marked disinterest in language standardization efforts (which I personally suspect stems from Wirth's involvement in Algol 68, although I have no direct evidence) led to each implementation rigging up their own ad hoc solutions.
As a consequence, even TeX, a batch program with no fancy demands on hardware, was not written in strictly "standardized" Pascal, but basically Knuth had to assume the existence of a number of non-standard mechanisms.
As you indicate, the language described in Jensen and Wirth's 1975 "Pascal User Manual" didn't have a way to open files with a name computed at runtime, nor was there a way to close a file. TeX needed to be able to do these things, as well as to have what C programmers would call a "default" case on a switch statement, which was also missing from standard Pascal. Happily, almost all Pascal compilers had these extensions; unhappily, the syntax was not generally agreed upon.
Other than that, TeX actually used a strict subset of standard Pascal; quoting module #3 in Volume B of Knuth's Computers & Typesetting: "Indeed, a conscious effort has been made here to avoid using several idiosyncratic features of standard PASCAL itself, so that most of the code can be translated mechanically into other high-level languages. For example, the `with' and `new' features are not used, nor are pointer types, set types, or enumerated scalar types; there are no `var' parameters, except in the case of files; there are no tag fields on variant records; there are no assignments real:=integer; no procedures are declared local to other procedures."
As you also say, Pascal had virtually useless string types, but TeX worked around that limitation itself, by managing its own string pool in a single big array of characters, with a second array of pointers to where each string started. A string was identified by its index in the later array. Through careful design and coding, no general garbage collection of strings was necessary, just the ability to forget the most recently-made string.
I've got that book, it is interesting to read. I also spent quite a bit of time looking at the Oberon system and that has been very educational. Oberon is quite like Pascal, but in some ways simplified even more. He wrote a complete operating system and user interface in Oberon and it is just amazing how much he achieved with very few lines of code.
I'm currently attempting to write a C compiler and the complexity is incredible compared to Oberon or Pascal. Sometimes I regret choosing C over Pascal as I'd probably be done now with the compiler, as it is I've only got the parser and preprocessor implemented.
Eiffel is another language that didn't gain a lot of popularity but is very interesting to read about. Bertrand Meyer, the creator of Eiffel is now at ETH Zurich, where Wirth spent most of his career. It's a very nice language that didn't achieve a lot of popularity, but some of the ideas, such as preconditions and postconditions, have been used in other systems.
I've written an Object Pascal (the current incarnation that Delphi/FreePascal uses) compiler/transpiler for Object Pascal->JavaScript and yes, it's great language for compiler writers because the language makes the job of the compiler so easy. You have to really go out of your way to make the compilation slow, and there aren't a lot of undefined behaviors or other gotchas that are hard to navigate. Also, I wrote it in Delphi. :-)
[0]: https://news.ycombinator.com/item?id=10058486