TL;DR: The way you and your team handles it depends on personal preferences and organizational influences. In my experience, most of the time similar behavior (same functionality) different execution paths tend to be duplicates.
Car Example
Scenario 1
Test Case 1: You get in and turn on the lights. Result: Nothing happens.
Test Case 2: You get in, insert the key, and turn to start the car. Result: Nothing happens.
I would log both issues because, from a test case perspective, those two tests failed.
Scenario 2
Test Case 3: You get in from the driver's side and try to start the car. Result: Nothing.
Test Case 4: You get in from the passenger's side and try to start the car. Result: Nothing.
Here, I would log one issue with details about each of the flows that I tried.
The mechanic (developer) realizes that the battery is dead and changes it. One fix solves the "issues". The root problem was the same for all issues, but as a black box tester, you can't presume to know that the root cause is the same.
That being said, you can use your judgement in whether or not the flow actually might be important or not. TC 1 & 2 are testing two different pieces of functionality, whereas 3 & 4 are testing the same functionality but from different starting points. Yes, there may be an edge case where the entry point to starting the car may matter -- but based on your knowledge of the application and past experiences, let your judgement be your guide. To CYA, always include as many details in the bug report as possible.
Org Influences
On a side note, as Joe Strazzere mentioned in the comments: metrics also play a role. Is QA performance measured by how many defects are logged? Does having duplicates affect that performance? Is Dev performance related to LOC, defects / KLOC, number of bug fixes, or just for meeting deadlines? The answer to each of these questions will dictate how each of the agents act in any particular case. In one organization where Devs are punished for the number of bugs in their code, they will do everything in their power to mark things as "Duplicates", "Invalid", or "Could not Reproduce," whereas in another company where Dev & QA performance is measured by customer satisfaction, they will be more willing to fix the issues.