this is the main issue I have with your argument- you’re conflating a common user experience with a feature. We’re not talking about ripping off Ferrari’s engine, we just want some side mirrors so we don’t hit things when we reverse.
1000%
Show me a programmer who tells me their algorithm is smart enough to understand a user’s intent without fail and I’ll show you a textbook example of hubris.
No,I’m not but clearly you don’t understand that User’s pov is different from Dev’s pov and this type of issue in not something new, it happened for example for selecting through visible.
Where users thought it would be a simple checkbox option when in reality it conflicts with many of Blender’s core design philosophies so it’s not a plain plug & play.
Hence why it was booted out until the design is laid out properly.
It’s one thing to wish for a feature and another to implement it in a proper way that adhere to Design doc that were agreed beforehand.
As someone who is both a dev and a user I beg to differ.
(edit for full disclosure: I’m not a BF dev, but I do development work on my studio’s internal fork)
Nobody here has said that it would be a ‘checkbox’. That’s on you. There’s a lot of good discussion in this thread about how something could be accomplished. It’s a conversation, not an action plan.
Right, and yet to even have a ‘design doc’ you have to start with a feature request, and a discussion on how said feature might work. Which is what this thread is for. You poo-poo’d the idea for some vague ‘Ton said so’ reason- Noted. Anything else, or can we move on please?
What’s up with your attitude? huh Relax and don’t take it personal.
What’s the difference then? make it clear, it’s simple to make a claim and not give the reasons behind it.
Read again and pay attention, I was refering to another feature that had the same roadblock because of users assumptions and if I understood clearly this feature will also become a “checkbox” overlay, since it would be optional or you did miss that point?.
And clearly haven’t read this.
This is a dedicated place for Blender module teams to reach out to contributors - development questions are welcome.
For feature requests, please use rightclickselect.com. For questions about how to use Blender, ask on one of the community forums.
Unless you’re willing to develop or contribute it yourself then feature requests are supposed to be on Right Click Select not here.
I mentioned Ton because you and the others have failed to comprehend that without his approval you won’t see this feature ever, mark my words.
Okay, I’ll sit ,relax and see how this unfolds, 3 years and counting 
I have a question regarding this, could you explain in a sentence why this is such a prominent topic for discussion in an environment such as blender which is supposed to be open source and open to the contributions of the community ?
Open source doesn’t mean that everything that is suggested by the community is going to be in by default, certain concepts and software designs are to be taken into account.
Otherwise you’ll have a disconnected features that only work for a niche groups as sub group of the community would want their own ways, so there must a balance to it.
Just because Blender is an open source doesn’t mean it has not structure or strict rules for quality control.
Open source doesn’t mean that everything that is suggested by the community is going to be in by default, certain concepts and software designs are to be taken into account.
True but there is a slight issue specifically to blender that i have noticed.
Suggestions are usually sent to “Right click select” where they inevitably die, well most of them die anyway, even good accessibility suggestions which would help with productivity etc.
Unless such a suggestion already has a developer working on that.
Otherwise you’ll have a disconnected features that only work for a niche groups as sub group of the community would want their own ways, so there must a balance to it.
In a sense i am frustrated with the Constraints and how broken they are, as only a couple o constraints are working properly as they were contributed throughout the years by random developers.
However people are building their own version of blender, K-Cycles, E-Cycles etc. as they change a lot of under the hood things and because they would never get approved because of their internal changes. So therein is the balance at least that’s how i see it
Just because Blender is an open source doesn’t mean it has not structure or strict rules for quality control.
Yes that is good, but again this is it’s limiting factor, mostly because developing for Blender you’d need to consult a lead dev to see if he would even approve an idea-to-addon/idea-to-implementation, so you have situation’s where an idea gets killed outright at the start, some create lengthy discussion etc.
Then we have situations where someone is already working on something and has created an addon and then he goes through the process of asking if it can be implemented into the Core.
I’ve read that people are having a bit of difficulty coding for blender as there is not a dedicated group of people helping the community in bridging Blender design philosophy and architecture, most of it has to be done by oneself through documentations or a lengthy discussion with a lead Core Dev, which limits contribution i guess.
Thank god that Left click select became a thing in Blender 
Blender being open source means that you can get current Blender version and allow eny developer to contribute to your own version of Blender, this is making a fork, of course this means that you have to deal with all the mainteinance when something from your fork collides with the master branch of Blender, IF you want to depend on it, if you don’t want to you can just fork it and go from there.
But the current OFFICIAL Blender version is maintained by the B.F. and because of that is the B.F. the one that decides what goes inside THAT specific version, but no one is preventing you or any one (like me with our build for example) to have a Fork with as many changes you want.
But with changes comes mainteinance, and that’s why they decide what they accept to the official version, because they have to maintain it.
It’s a limitation? sure, it may be a limitation up to some point, but it’s also a way to ensure continuity, to ensure a project as clean as organised as possible, and a proper mainteinance that allows developers to develop new features instead of having to be focused in mainteinance continuously.
Open Source means that YOU can do whatever you want, but that does not mean that the main dev teams has to accept a single patch from the community if they don’t want to, however they do because it’s beneficial for everyone, but those patches have to pass a review process and have to be accepted, some goes in, some don’t 
This is going off topic, but if you want to talk about such things then it should be somewhere else.
Hard to explain in words but what you are experiencing there is actually the reason why preselection highlighting is an anti-feature. I think we call it “selection cycling”? You click once and something gets highlighted close to your mouse, but click again without moving and it will select something different. This is a feature meant to help you select items regardless if they are occluded or not. So if clicking got you the wrong thing chances are the next click will get you what you wanted to select.
And it is this feature that makes hover highlight not work since what could be selected is not always the same.
Not commenting on the usefulness of the feature, just wanted to add this background as I didn’t see it mentioned.
And an equal chance that it’s not. And then when it happens (as in @ckohl_art’s example) it just looks like a bug. Sure, I get that it’s super useful when you have two cospatial vertices, but that’s a very specific edge case. For these more ‘general’ selections it’s far more useful (in my opinion, obviously) to give the user a consistent result that lines up with their expectations, IE) the element closest to the mouse cursor in screen space.
My experience with this is that whenever i have overlapping vertices and i want to select the one behind the one in the front i just cant select it, i have to change to workbench rendering and then i have to turn on xray and only then can i select the behind vertex.
Just show selection pre-selection highlight for first item in cycle list, then after the selection either a) don’t draw the pre-selection highlight or b) cycle the pre-selection highlight to the next closest thing most likely to be selected next.
A is probably the easier choice. Once mouse cursor is moved continue to draw pre-selection highlight like normal again.
It’s not as easy as it seems. Consider the simplest example of being in object mode with just two cubes.
Place one cube in front of the other. Click on the front one repeatedly and see it cycling between selecting the one in front and the one behind.
Now consider what would be highlighted with pre-selection highlighting - it is the opposite of what is selected. So just hover your mouse over a selected in-front object and the pre-selection highlight would be on the object behind - because that is what would be selected if you click your mouse next.
Exactly the point!
Active selection highlight(outline in case of object mode) and pre-selection highlight should be 2 different colors and overlays. Pre-selection highlight should also be rendered after the active selection highlight so it would be overlayed.
Also pre-selection highlight should be a semi transparent or dithered value so it could mix with the active selection highlight to indicate that there’s direct overlap in viewspace.
Blender’s selection cycling feature tends to fall apart when selecting multiple objects (for me, at least). For a single object you can just keep clicking until you get the one you want, but if you’ve already got a selection going and you’re shift-clicking you’re going to add every object that you cycle past to the selection; trying to deselect them has the same problem. It often happens when I screw up that I find it less hassle to just start the whole selection over.
Now, I say objects - with objects you can in fact hold Alt when clicking to get a list of objects under the mouse so you can pick one quite easily. But in edit mode that feature doesn’t exist (makes sense, I’ve not named my vertices; though I guess it could list them in z-depth order…)
Anyway, I think pre-selection highlighting would help, because I find I sometimes do have to click and guess.
I’d throw selection cycling in the garbage, in favor of pre-selection highlighting. hehe, even though they can coexist.