Programmers make mistakes in the category of "why didn't they learn from other people's mistakes?" in large projects all the time. In any project of sufficient complexity (not exclusively programming projects), you'll inevitably find something that falls into that category. I've typically seen this type of error as the result of trying to balance trade-offs of the "you had to be in the room at the moment" sort, and then you fix it later when it's a real issue for you.

I like that this post points out the issue, and I hope it gets fixed.

> The question is why material design didn't learn from other people's mistakes.

While reading the original material design spec, it seemed enlightened, but now its clear it's more of a standard than a best-practice. Its by no means the "best" design, just like the qwerty keyboard wasn't the best. However, due to a huge marketing push by google, it's now considered a standard and if you do not conform, you'll look weird. Not so different than in the 1990s, if you had a Windows application without a "file" drop-down menubar, you would also be considered weird.

Material design should not be thought of as an optimal design approach, it should be thought of as a standard to rally behind. If you build something adhering to the standard, regardless of whether it's a good or bad design choice, users will understand it because they have already been it by Google.

If you have something that's better, it may be rejected simply because folks weren't already trained on it.