Change cardinality between feature and release to 1:N

It just so happens that features are not finished within a single release and then there is problem with what to do. Create a custom status "unfinished" or make a cut at the finished work and clone the feature to next release to capture leftover work (option, that persists history). Or just move the feature to the next release without consideration of history (option, that puts the epic on roadmap at delivery time). Or create a master feature and multiple features for two+ releases, master feature put into release where it is finally deployed (combo option).

All approaches have few inherent flaws that are implied:

1) manual work

2) inconsistency when different people work it out manually in the company (everyone differently)

3) some epics with master features, some without => harder to show both information on single roadmap

4) distortion of logged work synced from JIRA - when feature is 1:1 to release, then synced requiremens (either subtasks or stories/bugs) are linked to that feature. When you create another feature to finish with leftover work, you need to remap stories and they might have work logged cross timeframe windows of the releases.

5) all mentioned before => impossibility to create proper reports and roadmaps showing the work done per feature

I have an idea for a possible way out of this. If features had cardinality to releases 1:N, such a feature could be implemeted via several releases (even with gaps, like in rel1, rel3 and rel5) and worklogs of synced children objects could be distributed per timeframes of the releases themselves based on worklog date from JIRA.

So out of current feature, we would have its parts finished in different releases .. I can already visualize a report showing what progress of a feature was done when. With GAPs due temporary stop on working on it for a release or two and coming back to it later. Lovable.

What do you think?