Refactor insert/materialize node schemas.

I'd be hard-pressed to say it doesn't fit with our style, as I think/hope our style is evolving.
There is probably some way to solve this that has very specific precedents in the current NValue API around pools and allocations, but since I have long/often been confused by those particular precedents, I can't advocate for following them.
Regarding your proposal, I'd have to see how this plays out to get some sense how deep the call stack is that has to deal with the two options.
I don't much like the idea of a single-purpose enum invented to tell one function what to do IF/WHEN all of the callers will just be hard-coding one value or another -- maybe I'm old-school, but to me that's what different function names are for. It MIGHT start to make sense to just add a variable to a single function if the choice of the option being represented was really a runtime decision by the caller (even better, by a chain of callers). But if the option is primarily hard-coded by the caller and has to be propagated down a long call chain via some pattern that is the same (or very similar) regardless of which particular value, I might consider templates. If the behavior difference could be associated with input arguments of different types, overloads might do, though I'm not actually a great fan of overloads except when they are used to enable templates (generic programming). BTW, that goes double for overloaded operators.