The problems aren't trivial, and sometimes the solution isn't trivial, but that doesn't mean there aren't strategies that automatically mitigate some of the issues. Using database transactions, verifying things worked correctly, rolling back transactions with unexpected results, not making assumptions like "two users won't change passwords in the same millisecond", and so on can protect your product. PHP and MySQL are largely to blame as so many web developers started out building sites on a database that didn't support transactions if you used the default engine.

Basic software quality assurance is missing from the majority of web development businesses.

How's that work when you set passwords according to id?

Yeah, this is my question exactly. I've dealt with MANY race conditions over the years and the idea that two different user requests could update the same user account password seems... unlikely at best. Not saying it's impossible, but more detail would have been appreciated.

I've seen this before in a Java system. A MVC Controller populated the HTTP params into a Bean, which it assigned to an instance field, and then used that subsequently to grab the value to update (don't think it was password, might have been email address iirc). This would work fine if the controlled was request scoped, but it turned out to be a singleton - so the field was shared across all requests!