It has been around 7 weeks since I first posted. I've been very busy.
The odds of this going into 1.5 are now pretty much nil at this time, so
there is perhaps time for a better solution. I can always hope for 1.5.1,
or 1.6/2.0.

  In answer to CGD's question of what other things get in my way... well,
I've only once had to define a new M_* type, and I think it may have been a
mistake. I have never defined a new mount option, but I can see that might be 
a problem. Soda's solution is quite ingenious, except that it loses the
ability for the compiler to check that all enum's are handled in a switch().

  I know that my proposed solution does not solve all problems. It solves
a specific problem for me, is very simple, and is easily done. Yes, it is
fragile, but it is no worse that the status quo. 

  I am less enthusiastic about CGD's solution of scanning the .o files for
constructor-like things. I've never been a fan of that kind of thing. I
didn't like it when C++ did this, and I still don't. 
  I agree with CGD: appealing to tool chain compatibility is a
red-herring. GCC is already the most widely ported and used C-compiler, to
the point that I'm not really sure why Sun, HP and IBM still ship their
own. I know that 3/4 of win32 environments that I've seen at customer sites
are using MINGW32 now :-)

  But, I'd rather have all of this explicit in a config file for the other
reasons that Soda mentions. Apparently this is being worked on. The question
is, can we consense on the concept ahead of time?

  I must agree with Chris Torek's comments: merge bdevsv/cdevsw, but perhaps
this is an unrelated task.

]     In Atlanta at N+I booth 4265                   |gigabit with big ACLs is[
]   Michael Richardson, Solidum Systems              |    no problem with     [
]     mcr@solidum.com   www.solidum.com              |     PAX.port 1100      [
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [