Part of the problem of mapping a work item to a requirement is being able to address the specific requirement revision. If it is always the latest then it is fine as the linking from the work item to the requirement will work whether it is part of a formal review or a collection.

So how do you reference a specific version (revision) - here are some ideas that might help.

1. For every milestone/iteration copy the requirements that will be changed by the request so that development can reference a specific revision copy - the copy of the requirements can be identified either via attributes or a collection name, and with maybe a link back to the original.
2. Alternatively from the artifact history copy the URL that contains the #revision extension at the end of the URL address and paste into a rich text document as a hyperlink. This rich text artifact could represents the requirements  for a release or milestone, similar to a vision document. The change requests would be made to the document.
3. Again from the artifact history use the revision URL but paste it explicitly in the change request rather than using the OSLC linking capability.

Now in regards to the future there is a concept called VVC that is being looked at that should help:

https://jazz.net/rm/resources/_oAktwNvCEeGAVYhYLFXCkg

Here's another, simpler approach (if you are using RRC v4):  you can move the requirements to a read-only folder when they are finished/approved. Then you have a controlled set of the "final" requirements for release 1.  Then for the next release you would copy the requirements that you want to use again (or evolve) -- with or without copying their links at the same time, depending on your process and needs.

This approach has some advantages:

• It's easy to explain
• All required actions are done through "normal" user interface activities
• Links between requirements and work items "just work" -- no special considerations required (except when deciding to copy the artifacts for release 2)