Had a crack at the wireframe color issue. I dont think its compatible with regular viewport wire drawing (which I think is why we rejected previous patches), but it could be an option like matcaps
Patch & Screenshot: https://developer.blender.org/D458
note, edits to posts on this page were because I messed up splitting the thread off initially.
Maybe itās the quality of the image, but the dotted lines make the viewport really restless. It kind of looks like these images particle physicists used the make to visualize track of subatomic particles in bubble chambers.
The stippled lines are quite noisy, which I think will create a little eye fatigue. Also, as you noted in the patch, the object colour can be used for other things (such as the materials) which could make it next to useless in a scene with a lot of objects sharing similar materials/colours.
If I could pose a small suggestion - I think the colour variable should be separate to existing ones, i.e. a new data value in the object/mesh structure. Secondly, I think the user should be able to select colours at a set luminance and the selected objects are displayed by increasing the luminance of the base colour. Using the colour-wheel widget - the user is limited to colours with the VALUE gauge turned down to about 0.3 and when the object is selected, the wireframe is increased in brightness (i.e. moving the VALUE up from 0.3 to 1.0 or thereabouts).
This sound reasonable/feasible (and yes, definitely off-topic now!)
@BTolputt. thanks for constructive criticism, This stuff isnt really hard, just has to be done carefully so as not to be really annoying for users. Im happy to update the patch and try some different methods of drawing.
but please post feedback on https://developer.blender.org/D458
edit: noted some possible improvements in the ticket.
I think it looks like a great start, thanks for pulling this out of your magic hat Cambell. This will be really helpful!
Is this colored wireframes version downloadable ?
Dear ideasman42, since I could not find a way to send you a PMā¦ first of all, a huge thank you.
Second, judging from the screenshot and the Bryce ones (if you have not gone to the page I linked, to it, as it shows the modeling with Bryce of spaceships with, in the worst case, 100253 objects used) I think that thin solid lines are more pleasing than dotted ones.
Third, +1 for a Matcap-like special display mode.
This is a really good start. I hope it can be expanded in the future so that it will be as functional as in other software that shall-not-be-named 
Thank you for making this patch Campbell. It has been a highly requested feature for many years and ignored for just as long.
Out of curiosity, what are the features that colored wireframes collide with?
Colored wireframe is the tip of the iceberg. There is much more work to be done in the modelling department without transforming Blender into a CAD like application. I do lot of CAD based work in Blender however I donāt need any parametric capabilites or cursor enhancements except when cursor works as knife tool. And I could see how my requests could benefit an enviroment modeller doing assets for a game or movie or how hard-surface modelling improvements could help someone doing organic modelling in a Blender production. I think this is the diagnosis Blender Foundation guys have failed to made reacting to criticisms to the Gooseberry project.
Currently wire color denotes selection, group membership, linked state, dipli-group members and in some cases object-type (set scene objects also have their own colors).
So to allow custom colors overloads existing colors with too much information and it means you donāt for example know if a green objects is in a group. or set to green by the user. (same goes for selectionā¦ other things)
Also, allowing custom colors can conflict with user preferences for 3d-view background.
So my patch ignores the theme for the background color and you can set wire to whatever color you like and you know anyone loading the file will be able to see the colors too, the same way you do.
The details, Iām happy to figure out along the way. Personally I dont mind the dashed line but seems not popular chooseā¦ trying something else is no big deal either.
Or someone could draw a mockup of what would work well.
Id like it if someone can really try to solve some design issues likeā¦
Of course I can make the decisions and commit it, but probably we get better results if others give ideas and we try some of them out first.
Iād argue that showing whether or not an object is in a group is not particularly useful. Showing which group the object is in would be much more desirable.
As for selection, linking and dupli-groups, perhaps that could be indicated by brightness instead? Or an outline? Or a bounding box? Or an icon next to the objectās origin while selected?
Also, linked duplicates are not indicated at all, and Iād say thatās much more important than group membership. Iāve lost much time in cases where I pressed shift-d instead of alt-d.
Active object could be solid&wireframe and selected objects opposite of solid/dotted lines.
So if wires are solid then selected objects are dotted and vice versa.
- How would you show the active object, selection?
Tough one. Do we have animated colours? 
You could use a not allowed colour here like the standard orange. See below. Or you could outline the selection. Or make the wire lines bigger.
- Do we want to allow any color, or should it be limited to a palette (like bone colors)?
When itās an either or, then i would say limit it. But why not both? Default it to a limited 8 bit or even fewer (16 Colors?) palette, minus the colours that are in use for other needs. And allow an advanced, free colour picking too.
That way you limit the colour confusion to the rare cases where you need more than 256 colours. Which is a very rare case anyways.
- Should colors be apart of some larger classification system? - or is simply setting a color per object nice and simple?
Define larger classification system. I would go for the colour per object though.
Well, there is the value/luminance suggestion of mine 
Iād go with the palette concept myself. One can even use the same three-colour sets. It also suggests an alternate to my luminance idea. The three colours can be used for selected, deselected, and active object.
Per object, nice and simple. The whole point to colouring the wireframes is to allow the user to create their own way of ordering the scene. If you try adding your own classification on top, it kind of defeats the purpose.
That help?
Well brightness is a good indicator in my opinion. If it is possible to make the āregularā objects appear in a darker tone than the selected/grouped/linked/etc then that is a good way to quickly note which objects are what.
Another example would be doing it the āMaxā way. Each object is assigned a random color from a palette that only excludes the āselected_colorā which is white. Max does not have any visual indication if an object is grouped or not but could be resolved by simply reserving a special color for grouped objects. Max also allows the user to manually choose a color for the wireframe with no restrictions, the user is assumed capable of not screwing himself over by choosing colors that are the same as selected/grouped/linked/etc and I think it would be nice for us to have the same trust.
In any case a palette seems like a good idea. Having a simple palette for regular objects to choose from and having a special palette for āspecialā items is good enough. Also it should definitely be a color per object (that the user may change if he/she feels like it.
If we can only set hue/saturation, higher value for selected, highest value for active.
A palette could be workable, as long as the palette doesnāt run out.
Colour per object sounds good. If a new object starts with a random unused colour, even better.
I tried once to get the selected object to have āfatterā outline, I think i remember it worked and was pretty nice visual feedback. I havenāt patched my version with the drawing code form that experiment though, i think it was a performance issue. The performance hit may be less now.
Could someone upload a build? I wanna see how this works 
ideasman42, thank you very much for this initiative! I tried your patch and think itās a good start, I like it overall.
Changing the viewport color is problematic for me, though. I feel that viewport color is a very personal thing, at least for me. I have set it to a medium grey, slightly bluish (#4A4F59). Itās very soothing to my eyes, I feel right at home and donāt have to think about it. When I turn on wire colors suddenly itās black, it feels very alien to me and I donāt want to spend much time there. I understand why you did it and maybe itās the only sensible way, maybe I just have to get used to it, but for me right now it doesnāt feel very inviting as a work environment.
I donāt have a solution, though, other than let us just choose the wire colors and trust that we donāt shoot ourselves in the foot.
Will think about it some more.
I think if weāre going to allow the user to set the wireframe colours to their choice in the new āwireframe colourā mode, it makes sense for them to also choose the background colour for the mode as well. They get to choose it for the other modes, weāre giving them a choice in the new wireframe colours (if even only choosing the palette), but weāre forcing a dark background on them - seems a little odd.
Is it possible to have a themeable background colour for this mode, Campbell?