The order in which buttons are added to a step is as follow:
cancel - back - next (in Firefox, there is a way to check tabIndex and they appear in the right order).
When on cancel (why cancel? Because this is the only available button on all steps), the script gives focus to the target, if there is one.
When in an target, the script gives back the focus to the step (using the blur event).
These are the only manipulations made. The rest is the browser deciding how to tab through.
Manipulating tabIndex is usually not a good idea, that is why we don't enforce anything more than what I explained.

Something is wrong then as it works correctly in the shepherd demo

It also works well when a step is not interactive.
In an interactive step, this behavior comes from the fact that once we get out of focus from the target, the focus is moved to the 'Next' button, if it exists and not disabled, allowing the user to move on to the next step faster. Therefore, going 'Back' can only be done with shift-tab.
We can give focus to the 'back' button first, no problem, but does it make sense once a value has been entered in an input field? But I understand it would keep it consistent...
BTW, we always go through the cancel button, it's just the way modals behave.

addressed elsewhere