I think you’re more excited by the prospect of using ‘anything’ as a clone source, not necessarily getting locked into doing it this way.
Lots of good and useful functionality seems to get deferred to doing things properly and not cluttering the code, though the “proper way” often never seems to get done.
from a user perspective this is quite bad.
Speaking in general terms here, not specific to this proposal, this is more of a problem with the open source development method - it can be too open sometimes Users get to see all the little experiments and ideas and first-attempts from inexperienced coders, that you’d never end up seeing in a closed source model, and can be easily tempted by the idea of that functionality, but are often shielded by the practical implications (at least directly). Almost a bit like wanting candy in the shop front when a more wholesome baked dinner is better in the long term
There are a few issues - firstly, functionality needs a good design and framework for it to fit into workflow-wise. Once you start adding nifty, easier to code tricks rather than planning and doing it the ‘right way’, it can get you into problems in the future when it needs to be extended. If more functionality needs to be added you’re stuck without elegant ways to do that if you continue piling on extraneous things onto a foundation that’s not really meant to deal with it. I mean this in a workflow sense as well as a code sense.
Taking the example of the grease pencil convert to curves button - the general idea of the functionality is good (drawing 3D curves with a tablet), and is the sort of thing that excites people, but the implementation of using grease pencil for it causes serious workflow limitations. What if you want a nice way to edit those strokes, like continuing a stroke where it left off, or editing or smoothing the points, or any of the other things you need to do in curve edit mode? It becomes a lot more clunky, switching back and forth between modes from disparate areas of the application (sound familiar? The ‘right way’ imo would be to implement freehand drawing tools within curve edit mode, which have plenty of room to grow within the established curve editing workflow.
And then you have the problem that if something’s been added already but you want to then get around to implementing it the right way, either you have to remove the old way (which people get annoyed about with both re-learning and also not being able to replicate obscure behaviour form the old way) or you get stuck with having multiple different methods for doing the same thing, which gets confusing to use and learn, but also doubles the maintenance cost. Remember when Brecht was proposing removing old features, this is exactly why - the more complexity that is added, the more effort it takes to maintain, finding obscure bugs etc. rather than working on genuinely cool stuff. Brecht seemed frustrated by this, and I was too, when I thought I’d be spending my time making good progress on developing good improvements for 2.5 but ended up having to fix bugs for several months.
Blender 2.5 has been stuck in ‘stabilisation mode’ for about a year now (i started my fulltime stint on 2.5 work last november), and a lot of this huge amount of effort has been spent on tracking down bugs. The more complexity, the more of this there is, and the less ‘right way’ the code is also makes things worse too. Of course users are shielded from a lot of this, making the rationale hard to understand, and especially so when the candy’s sitting right there on the shelf (patch tracker) out of reach. Perhaps there’d be more time to spend on implementing these features the ‘right way’ if there wasn’t so much icky code to fix in the first place
Anyway, I’m not trying to suggest that adding cam’s proposal will be the end of the world or cause these sorts of problems but I am trying to express that there are indeed serious costs to not doing things the ‘right way’, and that the bigger and more complex that blender gets, the more these costs amplify.