@include order hard to predict in complicated manifests

[ypcrts]

@include resolves recursively, but order is hard to grok in complicated manifests

this makes overriding one with another hard.

either: overriding within the same manifest in nested sections must be verboten; preflight panic
or: new destination macro, @force is an include you run in order, and ordering must matter, so refactor to use ordered sets for everything (for this i would use an ordered dict because builtin); and you must record @force sections recursively (implement using a queue because python recursion depth limit trash) to prevent a cycle

@force sounds like a lot of work for little. it sounds like poor design. maybe it is.

using different sections that can be manually constructed to cause a force is cooler.

[ypcrts]

I don't like the idea that @include'd targets should be ordered.

Consider *X means dereference X, identical to` \@include: X` 
C := { x=1, y=2, *G }
G := { x=4, y=3 }
E := { z=3, *C }

`toda install E` will clearly be order-dependent in its output, and this should throw. Does it?