Eh - it's really a conversation about how dogmatic you want to be here.
You have all the info you need with gitflow to go back to the state of a specific release, and then create additional releases based on that state.
Basically - there's nothing stopping you from going back to your 1.0 tag well after release 2 or 3 or even 4 are out, and then branching from there and creating a new 1.x release.
You have a wrinkle left over afterwards, since you now need to determine if any of those 1.x changes should actually make it back into develop (and this is really a case by case question) and you also (at least in my opinion) need a really valid reason for creating the extra maintenance of this wrinkle, but large paying customers can sometimes be a valid reason.
I think you have to tackle the same problem with TBD - there are certainly times when "spun off forever" is acceptable, but there are times when you genuinely want some of the work done on an old release to make it back into the mainline trunk.
---
Long story short... just prefer not to be dogmatic about these decisions and you can generally make most things work. Your customers don't give a flying fuck how you handle branches, and it should really be a consequence of what the team needs right now, rather than a "set in stone" process.