hook_update_71** run on D6 to D7 upgrades

Okay, upon closer inspection of the documentation for hook_update_n()...

Users can directly update from 5.x-2.* to 6.x-2.* and they get all 60XX and 62XX updates

However, this doesn't sound like a very good policy. In quite a few (most?) modules, the 6.x and 7.x branches are being developed simultaneously, meaning that many of the schema updates will be redundant between the branches. In other words, hook_update_6101 is likely to be identical to hook_update_7101, etc... So when users upgrade from 6.x to 7.x, they are getting a ton of redundant schema updates that break the upgrade process.

It seems fairly obvious to gielfeldt and me that the way this was probably intended to work (and is implied, though not stated explicitly, elsewhere in the docs) is that upgrading from 6.x to 7.x should ONLY run 70XX updates. This is supported by the fact that the docs refer to an outdated version of Drupal, and there has been traction in related issues (#1167996: UPGRADE.txt needs to say all D6 contrib modules need to be upgraded to their latest D6 versions before the D6->D7 update) since then.

Okay, if this is 'by design' then I guess this is a support request or feature request. But my original problem (described in the linked issues and in #2) still stands: how is a maintainer supposed to maintain 6.x and 7.x branches simultaneously, and allow 6.x -> 7.x upgrades? Again, the problem is that many of the schema updates are duplicated between the 6.x and 7.x branches, meaning that upgrades from 6.x-7.x fail.

As an example, let's say you have these hooks:

<?php
// Obviously this is pseudocode
function hook_update_6101() {
  db_add_field('new_field');
}

function hook_update_7001() {
  db_add_field('d7_field');
}

function hook_update_7101() {
  db_add_field('new_field');
}
?>

Perfectly reasonable, and yet upgrades from 6.x-7.x will fail because new_field already exists. This is a somewhat trivial example and is easy to guard against, but there are cases where it's much more difficult to guard against this. Assuming that the user is coming from the latest 6.x schema (a good assumption since #1167996: UPGRADE.txt needs to say all D6 contrib modules need to be upgraded to their latest D6 versions before the D6->D7 update) then only hook_update_7001 should be called on upgrade to convert to the latest 7.x schema.

Can someone besides gielfeldt and myself at least acknowledge that there's a problem here?

I don't want to mark this as 'major' again just to get attention, but I'm not sure what else to do. Keep in mind that it prevents upgrades to Drupal 7.x for at least least two projects and 3,000 users, and the problem will only grow if it isn't tackled early.

Thank you for clarifying, catch. I agree with gielfeldt that we should reconsider whether this is the best design, considering how much extra burden it places on maintainers and in many cases will prevent users from upgrading to later versions of Drupal.