Their advice seems to be "do not assume invariants on inputs". In which case you can only assume that your input is unescaped, right?
If you could assume escaping, that means you're limiting your input, which seems to go against the advice from my reading.
I gave escaping as an example, but one of the primary ways to reduce bugs is to reduce the scope of possible inputs as much as possible (thus reducing the scope of output to manage).
The requirements are different depending on the use case, but for application-internal code, not relying on that means that so much more global knowledge about the project is necessary to work on it. And, of course, a greater possibility of mistakes (because your requirements are more vast)
> Plus this advice is messy when it comes to things like string escaping. This could easily lead to issues like double encoding.
That's escaping - it's not the same as validation. What they mean is that you shouldn't expect that the invariants you see right now to hold in the future. It still means that you should only escape right before the data sink that requires it. But on the other hand it means: escape it right before the data sink, even if you see that the caller only passes in 2 different static strings - it may change. Or escape even if the current filter before rejects anything apart from digits.