Hi there - 

I'm thinking about how to do it .... I'm thinking a parallel action, where in one, you have your Request Approval - in the other, you have a "Wait until..." looking at the "Modified" date - then, inside that, a "Run If" which says "Run If date was modified and status is not Rejected or Approved", with a "Terminate Workflow" on the inside. 

That'd be one way to do it. There's probably many!

What if you have a second workflow on your list that starts on item modification and "terminates workflow" - all other workflows and then "start workflow" the same workflow if you need it to restart every time the item is modified?

or what about to go with opposite approach - if an item is being approved, forbide its changes.

this could easily be achieved by setting appropriate permissions.

Yes a valid alternative - what is your reasoning behind this requirement?  Will help us to identify the most suitable approach?

That's one good way to go.
When I'm using the "Request Approval" action the approval status changes to "Draft" right at the beginning of the workflow. In fact version number changes also changes to draft. 
So I'd have to check if this changing statuses/versions affects the "Modified" date. If thats true then I'm not able to monitor this easily.

Here lies one question of why using "Request Action" changes a previously approved document (say, a version 1.0 document) to a draft version 1.1.

But then the main point of my question is: On a regular Sharepoint 2010 OOTB approval workflow the workflow gets cancelled if the item changes (if this is set in workflow). This is even reported like this in workflow history. What happens behind the scenes then?

It's not necessary to restart the workflow automatically. Users are instructed to do that manually anyway (after all they want to review the changes made to the item before restarting the approval workflow).
Anyway, this is food for thought: These second workflow would run several times a day, with every change users make, and first thing would be to check if the first workflow is running. If so, then terminate it (the first workflow) and end. If it's not running, then just end.

I am actually reviewing and changing permissions in one of my workflows for different reasons, but this would be my very last approach, as it gets way too messy.

In the other hand, playing devil's advocate, haven't you guys ever receive complaints from users who, inadvertedly, cancelled a workflow because they changed something (missing to notice the workflow status) and only found out when workflow initiator got the notification? That would be a good (fancy? messy?) solution for that!

that's, imho, point of view.

if I were approver and should approve  the same request several times, just because firstly the request was send out not yet completed, then some typo was corrected, then some inadvertent change happened, then some justified change, etc., - that would be messy for me.

I've never came across a process that would require regular approval restarts due to changes to original requests.

of course, changes might be requested/needed. but that's usually task of process owner/key user or an admin. these are usually skilled users who can evaluate whether the change ca be applied directly (like correct typo, replace wrong attachment...) or it influences approval process (like more or less approval steps)  and approval needs to be restarted.