And forcing people to add a null parameter to their code all over the place is just ugly.
I agree with this, but I think the suggested forward migration path should be a situation where only the new methods are used, and every call will include a non-null string for collection. Leaving out setDefaultCollection would encourage this as well, so that sounds like a good plan. I think perhaps we should deprecate setDefaultCollection in CloudSolrClient as well, since it is not threadsafe and new functionality removes the need for it.
Deprecation gives the developer a instant clue that they are not using the class in the way that the authors intended. We can describe the design intent in the javadoc ... but deprecation gives an IDE user an immediate indicator that they should read that javadoc and change their code.
I'm excited about this new functionality. I'll be able to change code that currently creates sixty HttpSolrServer objects (56 for talking to individual cores, four for CoreAdminRequest functionality to the servers) so it only creates four HttpSolrClient objects.