Small correction: duplicates are not really "votes", but some managers at Apple do see them as speaking to impact of a bug, and almost everyone takes impact into account when scheduling the resources on fixing bugs. So if you want your bug fixed:
1. Do everything you can to show your bug clearly and reproducibly. No-one is going to spend much time on a bug they can't see.
2. Keep your bug report focused on the problem in front of you, don't stray off on tangents. That give the best chance that your bug gets fixed, rather than dismissed based on the tangents.
3. Include some sort of impact statement for your customers/organization. If this is causing lots of people serious problems, then Apple managers (and the screeners before that) are more likely to care about it more than some other problem that only causes a minor irritation for a few people. So don't just aim for a "+1", tell them how many people you DIRECTLY represent.
But some engineering managers don't care about duplicates, they relay on other things (sometimes only their own judgement) to decide impact and its relation to priority. But very few of us ever know which person is going to make those decisions, and what their priorities are, so it is better to always file your bugs (even if they get duped), and include impact in your filing.
If you want to make life easier for the screeners (who do most of the duping), then look things up on https://openradar.appspot.com, and reference a bug that already does a great job of deciding the problem there. But then include YOUR impact information.
I'm loyal to Apple to a degree that would get my US visa canceled if it actually were a religion, but even I must say that I don't feel like participating in anything like the process you're describing. I feel developers should actually boycott radar at this point. It's not just that the process you're describing involves an inordinate amount of my time for something that is at least as valuable to Apple as it is to me, only because the richest software company in history can't get its system to parity with github issues or – may Steve have mercy on my soul – bugzilla.
It's also that the whole process seems to be engineered to belittle the user who apparently isn't worthy of being informed of anything. Reported a bug in an API? Well, how about trying it after every release, or writing a test for it? Because you surly don't expect your tiny mind to warrant a one-liner or ticket change when we fix it?
JK! We actually have no intention to fix it. But you do enter the sweepstakes for the "One More Thing That Doesn't Work" award at WWDC for every year that your bug remains open.
But some engineering managers don't care about duplicates, they relay on other things (sometimes only their own judgement) to decide impact and its relation to priority. But very few of us ever know which person is going to make those decisions, and what their priorities are, so it is better to always file your bugs (even if they get duped), and include impact in your filing.
If you want to make life easier for the screeners (who do most of the duping), then look things up on https://openradar.appspot.com, and reference a bug that already does a great job of deciding the problem there. But then include YOUR impact information.