One thing that I think is crucial to a successful versioning strategy is to very clearly separate the versioning of the data structures in your payloads and the versioning of the operations that you need. If you muddle these two things together, you will tend to end up with a incoherent approach.
For example, let's say that you created an API with end point:
.../<employee>/management
and the data output contains this:
"manager": "Boss Hog"
Now all of the sudden you are told that the organization is moving to matrix management* and you need to support this in your API. So you change the data format:
"managers": [
{"manager": "Boss Hog", "type": "boss"},
{"manager": "Rosco Pico Train", "type": "sheriff"}
]
Don't get hung up on the structure or how you might modify it in a non-breaking way. just assume for the sake of this example that you must change the structure in a way that some clients can't handle without modification.
Note that the URI for this is still the same. This is really crucial because REST (HTTP) provides a nice feature that allows you to support this using custom mime types. That means that your payloads can evolve over time while the URIs are stable.
Now if you need to change the URI structures, that's where your URI versioning comes in. For your own sanity, I suggest that you version the entire thing together even if only a small change is made. Given that, you probably won't want to have to worry about trying to support multiple URI mapping strategies in the same code. By putting the version number up earlier in the path, it make it easier to deploy these separately and use a reverse-proxy to resolve things.
* I do not advocate matrix management.