Have you considered to use named branches for your feature branches? This way you can develop a feature by committing to it as often as you want, while the master branch is not polluted by these commits. When a feature is ready you merge the corresponding feature branch into your master branch. This will produce a merge changeset which only contains the difference between the feature branch and the master branch. When we started to use Mercuial we also used a workflow where we separated feature development solely by separate clones. However, since we use name branches life got much easier for us. The changesets are cleanly separated and you can have all branches within one repository without getting confused. Furthermore, you can switch between different branches easily. And as I said, you get a much cleaner history.
You seem to be branching off on every major release (12.0.0), then having possible minor updates to each (12.1.0), and hot fixes (12.2.1). Correct?
There's no specific reason why you cannot keep release branches alive in GitFlow after a release is out, other than the fact that coordinating changes between multiple diverging branches for a long time is hard with any model. I suppose GitFlow was also modeled more for products that maintain a single live release while developing the next.
I would stick with GitFlow and make a few amendments;
Skip the master branch. I've had no practical use of it so far, and it would lose its linearity the way you work. Keep development on the next major release on develop. If you decide to keep master, don't put release tags on master, put them on the last commit on the release branch that produced the binary you're shipping.
Don't throw away the release branches after you merge them back to develop. Instead keep them around for the next minor release and possible hot fixes. If you ever stop supporting a release, I suppose it's fine to delete them. You could name release branches after their main component, release/12, and then create sub-release branches, release/12.1, release/12.2 off of it. I've not had to worry too much about this level of parallelism, but that's probably what I'd try. You can think of each major release branch as its own sub-GitFlow environment in this case.
If you must be working in parallel on features for several future major releases at the same time, perhaps you have to keep the next one (13) on develop and anything for later versions (14, 15) on additional "develop-N" branches. That does seem very hard to maintain in general, but would be possible.
Best Answer
What I see a lot in the git/github community is this
branches master develop
You and contributors work primarily in develop, but someone may have an idea or new feature, so you create a topic branch like git checkout -b user_comments.
Then as you progress through the development you push to master once you git a version you are happy with and tag that in the master branch as 1.0 or 1.1.2 etc ( look up semantic versioning )