hook_menu processing should not assume 'file' is inherited

Wow. I think that is a bug in the menu system, not a documentation bug.

If you add a menu item in your own module, I don't think you should have to worry about whether the parent menu item you are adding it underneath has defined a file for its callback. You should be able to add items to the Drupal menu system without worrying about that, and you should not have to add a 'file' argument just in case the parent item (defined elsewhere) defined one.

Thoughts?

I'm marking this critical, since if this change is made (not inheriting the file component in hook_menu processing), it will have wide-reaching effects, and it needs to be done sooner rather than later.

And if this change is not going to be made, then we still have a documentation issue that needs to be addressed. To that end, I'd appreciate a clear explanation of why 'file' is inherited, and what your average contrib module needs to do in order to make sure they are not going to run into this problem if they add their menu item to a core-provided admin menu area (as we are asking them to do for IA purposes in D7, rather than defining their own top-level admin menu area).

Can someone explain how to reproduce this bug a little better?

I created a module that implements hook_menu as explained in the OP, and it works just fine in 7.x and 6.x.
I enabled the module, visited admin/build/modules/foo (and admin/modules/foo in 7.x), and received the expected result.
Then, I created a file named system.admin.inc in the module folder, and still no bug.

I found the snippets in menu.inc just to be sure, and the file and file path seem to be inheriting from the parent menu item, not looking in the current module directory as suggested in the OP.

(7.x menu.inc line 3184):

          if (!isset($item['file']) && isset($parent['file'])) {
            $item['file'] = $parent['file'];
            if (empty($item['file path']) && isset($item['module']) && isset($parent['module']) && $item['module'] != $parent['module']) {
              $item['file path'] = drupal_get_path('module', $parent['module']);
            }
          }

(6.x menu.inc line 2392):

        if (!isset($item['page callback']) && isset($parent['page callback'])) {
          $item['page callback'] = $parent['page callback'];
          if (!isset($item['page arguments']) && isset($parent['page arguments'])) {
            $item['page arguments'] = $parent['page arguments'];
          }
          if (!isset($item['file']) && isset($parent['file'])) {
            $item['file'] = $parent['file'];
          }
          if (!isset($item['file path']) && isset($parent['file path'])) {
            $item['file path'] = $parent['file path'];
          }
        }

Thanks for testing. Downgrading until we can learn more...

I think this happens under windows.

Here is another one I am getting

Fatal error: require_once() [function.require]: Failed opening required 'sites/all/modules/bulkdelete/node.admin.inc' (include_path='.;C:\xampp\php\PEAR') in C:\xampp\htdocs\...\includes\menu.inc on line 346

and possibly related:#952856: Fatal error: 'modules/scheduler/node.admin.inc'

Here's a place where this happens #952856: Fatal error: 'modules/scheduler/node.admin.inc'
I found it by enabling the UI module that ships with http://drupal.org/project/bg_image. It has this hook_menu():

<?php
  $items['admin/config/content/background-image'] = array(
    'title' => 'Background Image',
    'description' => t('Settings for how to apply the background image to the page'),
    'page callback' => 'drupal_get_form',
    'page arguments' => array('bg_image_settings_form'),
    'access arguments' => array('administer background image'),
  );
?>

Lines 3660 in _menu_router_build():

<?php
if (!isset($item['file path']) && isset($parent['file path'])) {
  $item['file path'] = $parent['file path'];
}
if (!isset($item['file']) && isset($parent['file'])) {
  $item['file'] = $parent['file'];
  if (empty($item['file path']) && isset($item['module']) && isset($parent['module']) && $item['module'] != $parent['module']) {
    $item['file path'] = drupal_get_path('module', $parent['module']);
  }
}
?>

Do we need this?

That code in #9 looks like it's trying to prevent the problems reported here. But it will only work if the 'module' values are set for both $item and $parent -- if they're not, the problem reported here would occur, so I'm guessing that either $item and $parent does not have 'module' set at this point in the code... perhaps?