This is correct.
The first paper to describe a stepwise model was by Royce in 1970 . The model he is describing is hypothetical and does not use the term Waterfall.
The first use of the word "waterfall" (including the quotation marks) is from 1976  and specifically refers to , the hypothetical model. In , the writers specifically state that "so few" projects fit this scheme.
If you were programming in the 80s and early 90s, you would know that no one in programming ever referred to a "waterfall" model.
Even Kent Beck's seminal book on XP, written in 2000, describes many failures of software development in those days, but he does not once use the word Waterfall.
So, in summary: the paper that supposedly describes it describes a hypothetical system; the paper that first uses the term mentions how little the model is used; the term wasn't used by people during the era it was supposedly most popular; and the folks who initiated the new generation of software dev don't refer to the model.
I think it's safe to say that it was not a thing. Or, to be more accurate, if it was a thing, it was never the thing it became until the Agile consultants used is as a strawman.
but it absolutely was very common to use the process that it implies.
many man-years of gathering requirements, building lists of features, interrogating stakeholders.
people knew they would never get a second chance to get what they wanted, so they would throw every feature in that they could think of.
Then the developers would build it. more man years building. mostly they tested as they went along, but....different features and areas of the app were often build in isolation, so the most you could say was that you had tested what you had built.
the stakeholders were consulted with screenshots, and sometimes the app, but the Big Fear was new features and additional requirements (which would cause massive contractual headaches) so any contact was VERY carefully controlled.
Also it was assumed every project was massively valuable IP, so detailed designs and features were held very close to the chest..again, any contact was VERY carefully controlled.
Eventually, after months or years of effort the various parts of the app would be "merged". omg the cluster fuck that would occur, the compromises, and arguments, the agonizing...
..then more testing..
Once that was completed the brilliant new creation would be seriously unveiled to the users to cheers and relief.
Finally, the contractual battles would begin as the paying company realised they had asked for entirely the wrong thing, and the development company tried desperately to cover their ass and make a profit.
The single biggest problem that Agile fixes isn't the testing, its the disconnect between what the client wanted and what the developers actually deliver.
There were also several books on the matter, and also revised waterfall models. The very term was not always used early on (though around the nineties it did), but the schemes were the same.
Lots of public projects, including some I've been involved, were designed and managed in such a way.
There were no changing requirements until the things were delivered, which could take 1-2 full years. The design phase resulted in monstrous 400 or 800-page documents covering every aspect, and to apply for such a software tender you needed to write those in excruciating detail (I did that too for several projects).
The waterfall model, with the name and all, was also taught at our university (early/mid nineties). XP wasn't even mentioned back then at our level, though we discovered it on our own, reading Fowler, Beck et al in the late nineties.
There's some tinfoil conspiracy theory thrown around that Waterfall was never a thing etc, and it was just used to push Agile etc. I wonder what its adherents did in the 80s and 90s, but surely not programming in large enterprise/public/military etc software projects.
(That Waterfall cannot work is another thing altogether -- nobody did it 100%, as nobody does Agile 100% today).
I ran projects that ran through a VERY traditional waterfall process as recently as 2010.
Waterfall still isn't dead and will never die because it's how people think by default, plan it all out, then build it. That's how buildings are made and thus it becomes the default methodology of all new managers who don't know what they're doing.