If entity doesn't change, don't create new revision

The behaviour you describe is correct by design of this module. But as you describe the case, it is indeed a little odd a new revision is made. So, I guess the start of a solution might be to look into developing a mini module which implements the hook_submit for the node which is under revision_moderation.

In the submit stage, you may check what piece of the node really changed and act accordingly. In your specific case, compare the submitted title and body against the current revision. If there is no difference, I guess you can unset $node->revision or give it a false/0 value. The result will be that during the node_save execution, the current revision will be overwritten, instead of creating a new one.

So I guess this solves your problem by adding some new logic. I would not write this into the current revision_moderation module as this logic might be different for each specific case. Good luck and give some feedback if you have some results.

I think I would call this a core bug. revision_moderation just deals with the revision stuff provided by node.module.

To anyone who tries to fix this, however, bear in mind that more about a node can change than just its title/body. For example, files might've been added or removed, or terms changed, or...

subscribing

We built something to detect changes, in a nodeapi call, we did a node_load on the nid (in the presave state) and serialized the results. We then took the node object from nodeapi, and serialized it, if they were the same, we made no change, if they were not, we added an entry to our audit table, might help here.

bump and subscribe :)

maybe field module issue now ?

Just in case anyone else is having this issue, a workable solution:

I tried #5 but went crazy having to filter the node objects because a lot of the data is different between the referenced node in presave and the result of node_load.

One solution I found was to node_view both (don't forget to clone the referenced node, else your referenced node will get modified something nasty) into rendered output and then compare. This had the benefit or flaw of comparing only fields which were set to display. However, I ended up tossing it because my page/teaser views didn't have taxonomy terms, and also had voting results, etc. This could be a workable solution.

However, I finally caved and just utilized the diff module which I had already installed. Here it is for anyone else who rather let diff module do the heavy lifting. It's still kind of hacky, but I hope diff will someday abstract out a comparison function that takes two node objects and can return something more sensible that doesn't need to be theme'd. (There's an issue for that.) A patch to core to prevent revisions if unchanged would be ideal.

    case 'presave':
      // Prevent revisions, if node is unchanged.
      module_load_include('inc', 'diff', 'diff.pages');
      $rows = _diff_body_rows(node_load($node->nid), $node);
      $result = trim(strip_tags(theme('diff_table', NULL, $rows)));
      if ($result == 'No visible changes') {
        $node->revision = FALSE;
      }
      break;

Is this still valid after #1723892: Support for revisions for entity save and delete operations?

I don't know how this worked in D7, but in D8 HEAD a new revision will be created only if the checkbox Create new revision is checked. If you submit the form and that checkbox is checked, then I think it is the proper behavior to create a new revision. This might be used as e.g. solving some kind of caching problems.
If you are not happy with this behavior you can always change it in a hook_form_alter or in an entity builder.