Oh shoot - I read your post, but then I just skimmed it again after checking fedidb and lost track of the context.
I think the point still hold that kbin is not at a point in its development where it makes too much sense for people to open independent kbin instances. By the way I understood it, mbin seeks to patch some of these problems, while the kbin development is focusing on improving the infrastructure on a deeper level. The drama is a bit silly, but I think forking is not always a bad thing and the differences in development between kbin (deep changes to the code base) and mbin (patches to make things work) are enough to justify parallell developments for the time being.
It's also worth noting that not a single new kbin instance has been created since September this year - I think for now you're unfortunately not likely to find an actively maintained instance beside the two run by Ernest.
Since Kbin was still at what Ernest refers to as a proof of concept stage when the project reached peak popularity, and I think at the time (and probably still) it was really not particularly easy to run an instance of. That's probably part of the reason why so many of the early Kbin instances died off.
According to FediDB, the biggest instances other than kbin.social are Karab.in and Kbin.cafe. Karab.in is run by Ernest who also runs kbin.social - it's just the Polish instance. As developments are happening fast (see !kbinDevlog), it's to be expected that instances not run by Ernest lag a little bit behind in development.
It seems the administrator of kbin.cafe is @barista. I'm not sure how actively maintained it is.
Considering the fast pace of development, I think it makes sense for the time being to either use kbin.social or an mbin instance.
It is really incredible how far down the drain the SCOTUS has gone in such a short period of time. Not saying it was great before Justice Kennedy retired either, but at least back then it was generally respected.