No....there is no "in between"...or even a need for that because knowing how to use config/framework, you can do it quite easily.
And honestly...it amazes me how much this confuses people.
An APPROVE step is just that....a person will look over the form and simply agree (approve) or disagree (reject) it. It is all read only (aside from adding a comment) and is pretty much like a "print" form.
An EDIT form/step is just that...if any ONE field must be available to change/update/modify, then yes, you have yourself an "edit" form.
Now, in order to make an EDIT form behave as you (and many others) like to do, you have MANY options. The most straightforward.....Make a new STEP in your form scenario (like "APPROVE_EDIT"). In your workflow, use an actual EDIT task and set the binding to the form scenario step. Then you can set your form fields based on that form step name to be editable or not and can handle it in your own generic service too. Since FORM_SCENARIO_STAGE is a "reserved" field in the framework, it handles it for us and always fills it in with the current form scenario step the user is viewing the form using. You can use this power/feature to then handle your form ANY way you like.