We hear you! I think they’re all valid concerns, arguments to the contrary aside (we haven’t really seen that many kit contributors/PRs).
Stam is right in summarising our main pain points as dev productivity (debugging) right now & conversion “determinism”, coupled with user experience: it’s much easier to handle and support one kit at a time properly.
Nevertheless, this does not need to be the ultimate approach. It’s the one we’ll start with as we want to kick things out in alpha; it does not block adding the same behaviour as in 1.0 back during the beta stage, and improve on that even with, for example, @Stam’s auto kit downloader & @daviddekoning’s UI suggestion.
Unverified potential code
It would mean, in the current architecture, creating a simple new “fake” kit, with one universal IConverter implementation that does what 1.0 does: reflect through existing kits, and invoke dynamically the conversion methods. It should be straightforward to grandfather in!
We just learned - the less we promise, the easier to deliver on, so I’ll keep mum about this (or at least put it under discourse’s spoiler alert flag 
PS: We’ve just posted another RFC on the Base Speckle Object in .NET. Check it out, hope you’ll like it!