Well, kischem comes very close to Kirsche (cheery in German) and kipfedit reminds me of Kipferls (sort of croissant)…
@c4757p
I remember back in… boah… 1993 or there abouts, 3D MAX was still 3D Studio and ran under DOS. 
They had these sub programs… one for drawing the 2D shapes, then another to make them 3D (loft, etc.) and then the 3D editor where you could arrange them and even another one to animate it all.
KiCAD somewhat reminds me of that time.
A linear approach to a user problem that is better served by a comprehensive experience.
But times and user interfaces have moved on - nowadays it’s all in one tool, one view. You draw the 2D shapes right there in 3D, the lofts, revolutions, etc. are all just modifiers in a stack of modifiers on the 2D data, you even animate it there - which is exactly the same approach modern open source tools like FreeCAD took.
KiCAD should go with the times. It’s KiCAD. The subtools are there, they have functions. But in the end they are modifiers on a stack of modifiers on data… the schematic, the layout… it’s KiCAD.
I know that an ECAD program should separate schematic and layout, no question, we need to be able to see both at the same time.
But depart from the old notion that KiCAD is ‘just’ a collection of linear standalone tools.
A modern point of view of an ECAD should see them as functions of it - of KiCAD.
And we have more and more use cases where this is becoming apparent… people want and need to go back and forth between the schematic and the layout to get stuff done.
The inter-meshing of those tools/functions needs to grow and intensify, they need to work/appear/‘feel’ the same - this also means they need to become and understood as functions of the ECAD tool and not as standalone applications in a collection.
And maybe get the gerber viewer integrated as well. Let it auto-update with the last settings and generate the views from the last known selection of files of that project if the user so desires.
And another thought on consistency - browsers vs pickers
If you were to incorporate the symbol browser in the symbol picker you’d have just one dialog to worry about, not two or three or four - the browser actually is the faster way to find a symbol and how often did I wish I could select it via those means.
What is the standalone browser there for any way?
If I want to browse I could use the picker and abort the action by not choosing something. I’d just hit [ESC] or click on [Cancel].
There is no need for a standalone browser at all really.
Same for the footprint picker and browser. It could be just one tool.
And the 3D model picker… you really found yet another way to design a picker - amazing 
.
Here is a tip for consistency, lazy bums and less problems (sorry for the smart-arse-ness):
#Write the picker once and then put it to use every time you need a picker or browser.
Same workflow for similar problems, no irritation, less questions, more satisfaction…
And to top it off, more time for the devs to work on more features instead of reinventing the wheel each and every time they come across the same problem (*) 
*) up there are 4 visually (and conceptually) different ways to pick a component/footprint/3dshape from a database (were the user is not really interested in how it’s organized under the hood - unless he has to go in there to do stuff that the developers didn’t consider). I bet those are also 4 different ways how one can code this. 
This means 4 times the maintenance and development effort, were just 1 time would have been enough. And 4 different ways of introducing bugs and regression faults. 
That’s 3 times of man power unnecessarily wasted. 
I couldn’t stop myself…
