Kyle, thanks, I saw your comment after posting my own, and I looked at Raymond's mailing list post that you linked.  I do think that "completing the grid" is a good thing in the cases where it's obvious how to do it (if there's one and one obvious way, then doing it that way should work), and having missing combinations in the grid is also a form of interface complexity (expect subset to work, find that it doesn't, and implement some hack).  Also it seems to me that sets, dicts, bags are basic data objects in many languages these days, without a lot of design space to move around in.  So we don't have to worry much about constraining future choices.  We could just look at Smalltalk or Ruby or whatever and just do what they did.  

However, that is philosophical.  I did learn from Raymond's message that Counter doesn't really attempt to be a multiset implementation.  In that case, it works for what it is made for, so it really then is a separate question of whether implementing multisets properly is worthwhile.  (That's as opposed to saying we already have a multiset implementation but some functionality is missing from it).

I dislike the concept of shovelling off basic functionality to 3rd party libraries.  The rejection of that philosophy (Python's old motto "Batteries included") is one of the things that attracted me to Python in the first place.  Though that value is mostly historical now, I'm sad about the loss.  It's impossible to write a large Ruby or Javascript (npm) application with 100s of third party modules, every one of which is an attack vector ("supply chain attack" is the current buzzword), and  whose implementations vary widely in quality and usability.  I looked at the docs for Ruby's multiset gem (https://maraigue.hhiro.net/multiset/) and they are partly in Japanese.  Python has until the past few years managed to keep away from that kind of thing.