| What you're saying is, you're going to completely ignore the issues
| around SMBus commands and smarter controllers.

Yes.  Providing SMBus compatibility will make it completely impossible
to talk to devices that do not use the SMBus command protocols.

| What that means is that when somebody comes along and does the single
| interface for both smbus and i2c _right_, they'll probably have to
| completely redo the interface between command issuers and command
| processors, specifically to accomodate representation of
| 'standardized' commands so that the front-end doesn't have to
| transform them into byte-ops, and the back-end doesn't have to
| recognize patterns of byte-ops and optimize them.

While an SMBbus framework can be built upon an I2C framework, just 
as a generic I2C framework can be built on the existing i2c_bus bitbang
operations, the opposite is not true.  SMBus controllers that handle
complete command sequences are incompatible with I2C.

| Read the SMBus spec.  Look at some examples of SMBus hardware.
|
| They're effectively the same bus with minor tweaks.
|
| Don't make some poor sucker have to do a whole bunch of extra work
| re-doing the existing drivers down the road because of
| shortsightedness now.

If your company wants to contract development of an SMBus, that
can always be arranged.....

Eduardo