Unfortunately, the better customer service doesn't provide better answers or solutions to problems, and the improvements aren't targeting long standing, basic issues with the platform.
This feature announcement fits the pattern: an improvement, but not in a critical area like indexing, or document-level locking, sharding stability, etc. There are basic fundamentals that need addressing like overcoming the 20K maximum connections per server, or mongos CPU usage. These are the things I deal with in production and that are business critical, but those feature requests sit untouched in JIRA for months or years.
This feature seems interesting, but it solves a problem I don't have. I'd prefer them to solve real world problems.
Right now my application stack is woefully under utilized due to this completely arbitrary decision on their part not to allow the end user to set the connection limit. They've even admitted that they just picked that number four years ago and haven't looked at it since.
Just like they limit replica sets to 12 members maximum. What if I have higher read requirements than that limitation allows? Well, too bad.
I think this points at a fundamental issue with MongoDB at the design level - they don't allow end users to make any decisions about how to configure the product, even if those decisions might turn out bad.
Every Enterprise-level DB allows end user tuning of parameters, so clearly MongoDB isn't Enterprise-level.
I think it is a little much to equate problems you have with being the only real world problem. Perhaps it's a real world problem that you don't have?
These aren't edge cases specific to my environment. They are very real, very visible issues that are discussed on the mailing lists all the time.