I think that workflow still fits.
In the more complex scenario I would create various feature branches. Merge these into master as and when they’re ready. Then reset the published branch to a commit on the master branch as described above.
So I’d still use merging (liberally), I would just never merge into the published branch directly.
Again this is essentially how anvil_extras does features. We always merge feature branches into master, then when they’re ready for the published branch we reset the published branch.
I agree that the word master is confusing. In the wider world of git the default branch can be named whatever you like. More recently the trend is to call it main.
Noted on the issue of inadvertently editing the master branch. I’ll add that to our list of things to improve.