It is like complaining about what were K&R C limitations, while ignoring most folks used compiler extensions and considered them C.
You also have to think of the effect of this on pedagogy in the pre-Google era. Any book on C would teach you how to handle arrays and strings of arbitrary lengths. Meanwhile, a book introducing Pascal would have to either restrict itself to the ISO standard's hobbled implementation of strings and arrays, or direct the student to cross their fingers and look at their compiler's documentation. That's a significant barrier.
I never saw a pure ISO Pascal compiler outside UNIX, and the only Pascal book I have, from several, that constrains itself to ISO Pascal is Niklaus Wirth book.
Additionally, Pascal naysayers keep forgeting that exactly because of ISO Pascal inadequacies as systems language, Modula-2 was born in 1978.
Quite a long time to keep comparing K&R C (with extensions) with ISO Pascal.
Specially given how many systems Apple shipped with Object Pascal in the box, or the sucess of Apollo Computers on its time.
I’m not sure where you are seeing 'Pascal naysayers'. I’m just pointing out an issue with the language that may have affected adoption. Neither Pascal nor C really got arrays 'right', but C never got in your way.
That optional extension became part of the ISO Extended Pascal revision, for example.
To make it clear should we compare Go's ability to write generic code versus other languages, using 1.21 or 1.0 version?
There is also the problem of not being able to define local variables (e.g. to hold the result of intermediate computations) right there and then. Even in Delphi until very recently, you have / had to declare each single local variable above the function body, below the function signature, _before assignment_. That is worse than C89 declaration style like used in Linux until recently (may be ongoing. I've dealt enough with that code to say that it's often a pain to have a lot of variables around that don't hold valid values.
So we already have two significant defects that produce friction in basic use. It feels like Duplo, not Lego, because important basic usecases require so much verbosity that it becomes cumbersomse to read and write. And I assume that is a big reason why the language has seen less adoption / has even lost adoption where it had already gotten some.
Some aspects of the Borland compilers (like performance) are genuinely nice though. And that it is in no small part due to the language structure enabling them.
Also for poor string and array handling. The classic implementations used a single byte to store the length of strings, and the length of an array was fixed and was part of its type. Though no-one could accuse K&R C of having good string or array facilities, the language was at least free of these absurd limitations.