I understand there is a lot of work going on "under the hood" which makes some features easier to implement than others, but from a user perspective it is hard to get one's head around the seeming mis-prioritization of the development work that CERN is doing. For instance, we now have length-matched traces. That's awesome, and no doubt essential in a professional tool, but given the fundamental usability issues it seems like misdirected effort to me. My personal gripe list:
1) Vias are still not treated as "first class" objects and there is no roadmap for when this will happen. It is not clear that the devs agree with the proposition, which is extremely worrying to me. By "first class object" I mean that vias must be seen as independent objects you will sprinkle around the board, not related to traces in any way. gEDA, for all its problems, got that right. The approach taken by KiCAD currently is that vias are, first and foremost, a means to hop a trace from one layer to another, when in reality this is the worst usage of vias in good PCB layout. (Admittedly all PCB layouts will need to do this, but we try to minimize it.) Workarounds using fake traces are tiring, and if you don't do it right, KiCAD deletes the trace and its vias forcing you to start over. This is probably my #1 efficiency killer with KiCAD right now.
2) Filled zones are just weird. First there is the issue where you cannot have zones inside of other zones, unless you manually tweak a "priority" number in the zone properties. First of all, why?? And second, who is going to associate the word "priority" without being told that's what it means? Zone filling and display is also inconsistent, and it's weird that you have to run DRC to see the zone. Finally, editing the shape of an existing zone on a crowded board is extremely difficult, because there are not well defined and marked control points. (Lack of clear control points is a deeper problem affecting other objects too, like traces.) I usually give up and just delete the zone, then create a new one.
3) The abysmal library interface is frequently mentioned, and for good reason. I don't mean to sound insulting, but there are aspects of the "select a part to edit, edit part, save library" workflow which are so hilariously bad, I honestly cannot fathom how they came to be. My favorite is when saving, you have to click through three (or is it four?) dialogs to say Yes, I want to save this part, yes I want to save the library, yes, I really mean it, yes, d??? it, yes!! But whole thing desperately needs a redesign. The only saving grace is that you can create footprints by hand in a text editor. Thank god.
4) Standard parts library is just as bad as gEDA. Completely non-orthogonal, and, 90% of it is bizarre ancient parts no one is likely to use anymore. This is a huge challenge and I don't have a good answer, but at a minimum it would be nice to have a gatekeeper. What is already there would become substantially more usable if you just deleted the least-used half of it. Beyond that, some sort of integration with an online parts database seems like the way forward. I don't think the github scheme is doing it
5) This is petty, but some of the terminology in the program needs sanitizing so a typical EE will understand it. Do they still call footprints "modules" for example?
I am sad to say that my [very limited] experience with the devs on the bug tracker has been similar to that reported above. I am not sure if they are practicing EEs, based on some of their responses. When you attempt to explain how the software will actually be used in practice, they can get defensive. When I asked for help with zones inside of zones, the first response was "Why would you want to do that?"
although to their credit they did go on to explain the priority thing.