My requirements experience has been primarily with user stories, not use cases. I've been recently added to a project as a product owner, and the customer is ~80% done with the use cases. Many of the use cases include what would be over a dozen user stories, and the team is discussing how to implement some of the use cases over multiple phases, or how to partially implement to meet schedule. This wouldn't be a problem with stories, but I'm not sure the best way to approach with use cases.
Can a use case ever be partially implemented? Or would that mean that it should be decomposed into smaller use cases with extends/includes? If it can be partially implemented, how do you track individual features so high-priority items do not get lost?
For example, if I have a single use case for a spell checker with the following:
How would I go about prioritizing the individual features and then tracking implementation of features 1 and 4 in one phase, 2, 3, 6 in second, 5 in a third, and not implementing 7? In this example, should these be separate use cases, or one with multiple alternative flows?
I think you are confusing benefits of UML use cases (show what a system does) with what project management tools and issue trackers should do for you (keep track of implementation and priorities).
Yes, you can split up use cases with include / extend. That makes a lot of sense when you show how they decompose. You can also draw use case generalizations.
For keeping track of implementation stages, it is probably best to put your complete UML model under version control (some UML tools come with support for version control) and have different versions of the same diagram.
You might also use e.g. different colors to indicate implementation stages. But then don't forget to create a corresponding legend and keep this updated. Also don't show future use cases to lots of people at random. The temptation to do unneccessary work prematurely might be high (remember YAGNI).