I like to conceptualize it as having a "waterfall shell with an iterative core"
It is not uncommon for us to have new requirements added in the middle of a release. However, once safety testing and clinical validation are performed, changes are pushed to the next version unless a huge safety issue is detected.
This really isn't true, at least not for this context.
As far as regulatory submissions go and the design outputs that get stored in your QMS, the SDLC appears waterfall because there are clearly defined design inputs, design outputs, and verification / validation checkpoints. In practice, however, the actual process can be agile.
I would word it differently, that the set of documents in your DHF, MDR, 510(k) filing, etc. are identical regardless of the methodology you use to create them.
Some of the language around them sounds "waterfall-y" but you are perfectly welcome to iterate on these documents. The documents themselves are more about engineering practice than process, and are an output of whatever process you use, much like the software is.