I recently debugged through a case where this was a problem with non-ASCII usernames. Through an upgrade of an underlying docker image the default system encoding changed from UTF-8 to ISO-8859-1 and nobody noticed. This even passed QA since they always create new users in their test cases and the bug only occurred if you wanted to log in as a user with a non-ASCII character that was created with an old version of the service.

That doesn't mean the fault was not on us. We should've made the encoding explicit rather than relying on the system default.

Long story short, encoding problems can be tricky, even in 2019.

For an implementer it is a bad excuse in 2019.

For a user setting a password it is unfortunately still reality in 2019, even if probability to hit such a system is slowly decreasing.