Which is very easy to do without losing any desired functionality as opposed to delimiters in the ASCII character range.
> and you need to consider possible truncation scenarios
In particular hashing libraries worth using never have this problem.
> and make sure they won't cause silent failures at any point.
They literally only need to exist in the data to one function call. Afterwards they are not needed or significant.
One pattern I bump up against from time to time is the delta between using a perfectly defensible technique for a given use-case (safe delimiters when constructing an input for a specific function) versus a desire to have each decision be driven by some universal law (e.g. "if you're streaming data between services, using null bytes as delimiters might not be safe if consuming services may truncate at null bytes, so NEVER use null bytes as delimiters because they can be unsafe")
It's not even a matter of one "side" being right or wrong. You can simultaneously be right that this is perfectly safe in this use-case, while someone else can be right to be concerned ("need to consider possible") because the code will forever be one refactor or copy/paste away from this concatenated string being re-used somewhere else.
I'll note that the reason we're here in the first place is that they were using a password hash library with a completely unacceptable API.