This is the exact issue I have with gitflow and GitHub flow, and it seems that with web applications this happens often - or more like the norm. It seems you would either resolve this issue retroactively (mentioned above) or proactively (example below).
I've created 'bundle branches' in addition to the standard gitflow branches. The bundle consists of all the features that are ready for uat/qa. A list of uat/qa features are created. These are merged into the temporary bundle, and that bundle gets deployed to uat/qa. Any bug fixing happens on the original feature branch, and that gets remerged back into the bundle and deployed. This separates the coming release as well as allows testing those features together prior to them finding their way to the develop branch. Those branches that are approved get a pull request into develop - following the gitflow process. Test ready features can be added to or removed from the temporary bundle branch
- This keeps master always reflecting production-ready state (can automate with hook)
- Develop always reflects latest delivered (and tested) next release candidate
Cons include managing the bundle list and adding another branch type; however, besides the retro fix, which I think is too late, this seems to be the more viable solution.
With a GUI addon, it might be optimal to tick off feature branches per bundle deployment - with automation in mind.