Ignoring your project methodology for a moment, the end state of your repo after such a feature is delivered should be:
- You have a new tag with an incremented version number, and the difference between it and the previous tag is the new feature.
- The main line of development (trunk) includes the feature too, such that new branches get the feature, and existing ones will get it next time they sync up with trunk.
How you get there depends a bit on your repo layout and its conventions, but here are two options (which appear to correspond with what you don't like):
On a new branch off the current tag (or an existing release integration branch that clean), complete the feature/bug fix, create a new tag and release, and merge the tag back to trunk. Good option since it minimises risk that unwanted changes are released with the bug fix. The merge back to trunk might be difficult if much has changed.
Complete the feature on trunk first, cherry pick it to a new/existing clean release integration branch, tag it and release it. Good because others get your feature/fix earlier. The merge to the integration branch might be difficult which might slow down the release.
I think Option 1 is best since it will generally be quicker to release since any merging is postponed until the changes are ported back to trunk, and there's less risk of unwanted changes leaking into prod.
As far as your project methodology goes, if you are to accommodate the feature, you must either;
- Reduce scope of current iteration
- Delay release of current iteration
- Get additional resources (developer/s) or do overtime to build the feature
... Or some combination of these.