As far as use case diagrams go, I tend to agree with Martin Fowler's thoughts on the subject:
Use cases appear in the UML in the form of use case diagrams, but these diagrams are of little value - the key value of use cases lies in the text which is not standardized in UML. So when you do use cases put your energy into the text.
If you consider other methods of capturing use cases, such as a tabular format, you can annotate them. If you search for formats for capturing use cases, you can find plenty of examples of textual and tabular formats. In one of these formats, it would be much easier to annotate the fact that a particular use case or even a particular alternative flow or alternate course through a use case only exists in one platform or version of the application.
All of that said, there may be value in using a diagram as a "map" to your use cases. If you do decide to include a UML Use Case diagram, you can focus on linking actors to use cases which have a more detailed description in your textual or tabular formats. In the diagram, simply link the actor(s) to their use cases and in the use case symbol, indicate the name or identifier of the use case and use the tabular or textual format. In this particular example, an actor would link to an "edit catalog item" use case and the reader would be expected to read elsewhere if they wanted a deeper understanding of what it means to edit catalog items.