Is it just me who finds this poor style and potentially confusing:

<?php
function my_function($nodes) {
  foreach ($nodes as $nid) {
    // do stuff
  }
}
?>

To me, a variable names $nodes will be an array of nodes -- that is, node objects. If it's an array of nids, I would call it $nids to avoid confusion about what we have there.

I'm curious if other people agree (in other words, is it worth my time writing a patch for core or will it just lead to bikeshedding?)

In general, though, I think it's a good idea for variables to be named in such a way that describes what they hold; also for the same data to have the same variable name as it travels through functions. In other words, avoid this:

<?php
function foo() {
  bar($ponies);
}

function bar($caterpillars) {

}
?>

Unless there's a good reason, say if bar() is generic and can accept any animal. In which case, call its parameter $animals, obviously.

I've been mulling this idea since Paris, trying to figure out the best way to present it.

But basically:

We want a smaller, slimmer, efficient core.
But we also want Drupal to, like, be useful.
We want contrib, at least the high-use end of contrib, to be smoother, more organized, released on time with core.
It's been suggested we have a contrib maintainer, who would have the unenviable task of managing a huge kaboodle.

So on the one hand we want to move things out of core, into contrib: things like poll, blog, even forum and profile. However, moving out to contrib is currently recognized as being a death sentence for the code itself, and dooming users to the curse of a million Lego bricks (to quote webchick).

On the other hand, we want better underpinning for the contrib modules that really make Drupal what it is: views, CCK (what's left of it out of core), panels, flag, voting, token, and so on.

These two things actually seem the same to me: define an Outer Core. This would be a fairly loose collection of modules, not simply the 40 most popular, but those that provide important functions, play well together. Outer Core would get a maintainer or two, to ensure good use of APIs, generalization and abstraction of common code where possible, no duplication of code or features, and plan releases.

Drupal the framework would be just the core.
Drupal the product would be core + outer core. We'd release both simultaneously, available as a single download.

End result, I hope: we tame a sizable part of the Big Lego Brick Box.