DFW and metadata operations subject to transaction control are artifacts
of supporting direct update of system tables. There were a number of
reasons that I wanted to support direct update of system tables in
Rdb/ELN and Interbase, but based on reflection and experience, I'm
willing to concede they were wrong.

The original Interbase engine didn't not have support for DDL, nor was
there a generally accepted DDL to support. This is not longer the case,
however.

The pre-Vulcan implementation of SQL DDL is layered rather than
integral, which requires support for direction update of system tables.
Vulcan, however, pushes "dsql" into the engine proper, and could
dispense with direct update of system tables in entirety.

I'd like people to think about the implications of dropping support for
direct update of system tables in favor of internal engine support for
proper SQL DDL. The implementation would certainly use an ad hoc
special transation committed or rolled back on a per statement basis.
The same semantics would probably makes sense to retrofit over DYN,
which I wouldn't mind dropping, but probably isn't feasible to do so.

Decommitting direct update of system tables wouldn't necessarily
eliminate DFW immediately, but would turn it from a general mechaninsm
into one restricted to support well defined, bounded, internal requirements.

Thoughts?