Not much of a question, rather request for comments.

Basic ideas:

VyConf is standalone, you can make your own appliance by adding your own config definitions and scripts. This means no assumptions about environment (though appliance script still can make any assunptions of course).
Rationale:appliance making is popular and useful. If more people can use it, more people can contribute to it.

Command (config path) definitions are completely separated from config scripts.
Command definitions are in XML, a RelaxNG schema is provided for validation. In VyOS and any vyconf-based appliance validating definitions against the schema must be a part of automated tests.
Value checkers can be extended via external scripts.
Rationale for separation: mixed embedded and external scripts make code hard to navigate and test.
Rationale for XML: it's the only format with readily available tools for verification and transformation. With RelaxNG or XSD one can verify that it complies with intended grammar, with XSLT one can transform it to any other format (e.g. HTML or DOCBOOK documentation).

Running config and session configs use in-memory representations.
Rationale: UnionFS-based implementation from Vyatta routinely creates permissions problems when the config is modified by scripts and, as it's file-based, performance problems and enormous amounts of system calls for every config operation.

Config AST manipulation functions are standalone and can be used outside of vyconf process.
Rationale: Vyatta implementations duplicates config parsing and manipulation code just so migration scripts can do their work because functions from libvyattacfg cannot be used outside of a fully initialized Vyatta system. Making the functions for config parsing and raw AST manipulation standalone will make it a lot easier to write migration scripts and external tools (config analyzers etc.).

Config read and write operations are performed through the same API.
Rationale: Remote access API can be supported in natural way. No need for separate APIs for internal scripts and external clients, they can use the same library.

VyConf process uses sockets for all API calls.
Rationale: system and language agnostic.

Commit is fully atomic. Commit is multi-stage: first the proposed config is verified by scripts from every component, then actual configs are generated and services are restarted.
Rationale: current implementation makes it easy to end up with a system in an inconsistent state where config is only partially applied, because it every component's verification and config update procedures are run sequentially. If incorrect configs stop commit before any real change to service configs is made, probability of entering inconsistent state is greatly reduced.

Configs for target applications are produced by programs/scripts that are called at commit time, read the config, verify it, produce target config files, and apply changes or restart daemons.
For every target application, there are three scripts (or thee functions in the same scripts invoced by calling it with different options): "verify" for config checks, "update" for producing target configs, and "apply" for restarting services or applying changes.
Scripts read the system-wide config through API calls to VyConf that return it in serialized (e.g. JSON) format.