I'm not quite sure where I stand on /dev/cuaXX (since physically separate
autodialer devices are ancient history), though I think that "everything
should be as simple as possible but no simpler" may be a better motto than
K.I.S.S. -- the trouble being that I don't know if user-level tty locks
are simpler than is possible :-).  However,

> BTW, I think having multiple tape/floppy devices for different densities
> is an icky hack too, but having a character and a block device for one
> physical device isn't.  Also note that in these cases there's no hidden
> lock information being managed inside the kernel (or at least I hope
> there isn't!).

When I was at CRDS, we almost added a "floppymodes" command to replace the
plethora of multiple floppy devices, mostly because we were out of bits
to represent new formats.  "Fortunately", UNOS pretty much died before the
floppy manufacturers came out with the next format...  Note that it would
be pretty irritating if you implemented the UNIX tty driver trick of resetting
to a useless mode set on the last close (however, the UNOS tty driver didn't,
so we didn't have any philosophical problem to overcome :-).  UNOS also had
the block/character distinction, but there was only one device table, hence
only one set of device numbers (nice), plus our mount program didn't care
whether you specified raw or block.*

I think a difficulty with the floppymodes idea is that a program which wishes
to try floppy formats until one works can currently just step down a list of
pathnames, but would have to be changed at least to a list of system() strings.


* You could, in fact, create a block-buffered tty device, and we amused
ourselves one day by mounting it.  The novelty instantly wore off when we
suddenly perceived the tediousness of typing in several K of binary data
on a 7-bit terminal without prompts...