When dealing with different frames of reference interacting with each other instantaneously, you have to compromise somewhere, you cannot have everything consistent everywhere; that's a fact of life. The scenario you have outlined is basically this: the shooter thinks she has hit her target, but the target thinks she has successfully hidden behind an obstacle.
Who is right? That's for you to decide, but I'd argue that games that emphasise shooting - with fast projectiles - should favour the shooter, whereas games that emphasise moving and evading - with slow projectiles - should favour the target. (You could of course do both in one game depending on factors such as the speed of projectiles.)
- If you favour the shooter, then you can give instant feedback to the shooter on whether she has hit or missed, but the target's feedback on whether she was hit or not will be delayed.
- If you favour the target, then the reverse is true.
In practice this tends to end up in the shooter's favour, as most FPS games have fast projectile weapons that require instant feedback for shooters, but keep in mind that anything you decide will be a compromise. Also, contrary to many gamers' complaints, it is the sum of latencies between shooter and target that determines the severity of the compromise, and in one-on-one encounters there is no inherent advantage to either player - both players experience the same degraded gameplay, irrespective of their individual latencies to the server.
Here are some general strategies and examples (the Gaffer on games article expands on some of these concepts):
Server authority (listed in the article as Client/Server): this is where the server is the ultimate authoritative frame of reference for everything, including whether one player has hit another. This was common in the early days of internet FPS games, when titles like Quake were most popular. This disadvantaged all players for the sake of the game, and disadvantaged high-latency players more, as no action begins until the server hears about it. For twitch-shooters such as Quake this was acceptable, as one needed a low latency to get the best experience anyway. The downside was that even modest amounts of latency - 100-150ms - was noticeable for human players, and they had to compensate by aiming ahead and so on.
Client-side Prediction: often goes hand-in-hand with latency compensation, this is where the client is the authoritative frame of reference (either the shooter or the target, as I mentioned), and the server maintains a buffer of previous state in order to validate the client's prediction. Games using this architecture became common in the early 2000's, especially for "realistic" shooters using fast projectile weapons such as Counter Strike.
Latency caps: to mitigate the harmful effects introduced with client-side prediction, many games and server admins chose to disallow high-latency players from playing. This ensures that the experience is consistent for the low-latency players. Although this seems harsh, with the spread of broadband internet and matchmaking services, the pain can be reduced.
Latency-capped client-side prediction: this is the same as client-side prediction, but where the compensation is limited up to a maximum latency. Any players above this threshold will only have their latency compensated up to that threshold, no more. This threshold should suit the nature of the game, but 200ms sounds like a good compromise. This means that for players with latencies below the 200ms, it's identical to normal client-side prediction, except it feels like no one has a latency any greater than 200ms. For players with latencies above the threshold however, it feels like a server authority game where everyone else has a latency of 0 but they have a latency of X - 200ms. I'm not aware of any games that do this but I'd be surprised if this has never been attempted before.