Some time ago, I observed on a client project that version id (vid) was not equal to node id (nid) even though Revision/History was not enabled on this instance. Weirdness. In the end, it turned out to be something goofy with a mysql crash botched recovery and data restoration at the datacenter, but that's a tale for another time (perhaps over a beer at Dallas Drupal Days 2012?)
So I am trying to create a new "shell of a Drupal instance" for the client with some stub data. This Drupal 6 based portal was never deployed atop profiles or Drupal Build Tools, so I put on my mud boots, grabbed a shovel, and started wiping out content directly in the db picky-choosey style. Turns out node_revisions still has to have something in it, but since I wiped it completely, I'll continue with my story.
node_revisions.nid is a normal field, but node_revisions.vid is one of the rare instances where Drupal takes advantage of the native database features like autoincrement: Empty node_revisions and new nodes give old new nid and brand new vid! See image:
Check your own installations: You'll see that probably nid == vid for most instances.
When can nid != vid be a problem? When you're starting out and you don't consistently include nid AND vid in your queries in some instances and rely on vid in others....
Because I had cleared out node_revisions, I am seemingly unable to delete some content. Doh!