It’s actually a warning, but I guess you use --fail-on-warnings, which is generally a Good Idea™.
You have encountered one of the exceptions in the YANG 1.1 support - from the “YANG 1.1” section of the confdc(1) manual page:
o Type leafref in unions are not validated, and treated as a string
internally.
(In YANG 1, type leafref is not allowed to be part of a union.)
You can prevent the warning from becoming an error when you use --fail-on-warnings by passing -W YANG_ERR_UNSUPPORTED_TYPE_IN_UNION to confdc, or you can suppress even the warning by passing -w YANG_ERR_UNSUPPORTED_TYPE_IN_UNION.
I’m afraid you must be making some mistake when changing the compilation options - maybe you have some generic make target that is applied? I verified what I wrote before posting - here it is, where I faked your eci-bgp-l3vpn-dev.yang module as containing only the typedef, and used ietf-interfaces revision 2014-05-08:
$ confdc -c eci-bgp-l3vpn-dev.yang
eci-bgp-l3vpn-dev.yang:12: warning: the type leafref (defined at ./ietf-interfaces@2014-05-08.yang:54) is converted to 'string' when part of a union
$ echo $?
0
$ confdc -c --fail-on-warnings eci-bgp-l3vpn-dev.yang
eci-bgp-l3vpn-dev.yang:12: error: the type leafref (defined at ./ietf-interfaces@2014-05-08.yang:54) is converted to 'string' when part of a union
$ echo $?
1
$ confdc -c --fail-on-warnings -W YANG_ERR_UNSUPPORTED_TYPE_IN_UNION eci-bgp-l3vpn-dev.yang
eci-bgp-l3vpn-dev.yang:12: warning: the type leafref (defined at ./ietf-interfaces@2014-05-08.yang:54) is converted to 'string' when part of a union
$ echo $?
0
$ confdc -c --fail-on-warnings -w YANG_ERR_UNSUPPORTED_TYPE_IN_UNION eci-bgp-l3vpn-dev.yang
$ echo $?
0
$
Good to hear! About the confdc command you quoted, it’s a bit weird in that you are compiling eci-bgp-l3vpn.yang but request that the fxs file should be called eci-bgp-l3vpn-dev.fxs. In principle you can call the fxs files whatever you want, but it gets confusing if they don’t match the .yang name - and in some cases you actually need to compile and load deviation modules “themselves”.
That’s a possibility (for some value of “properly”), but since we don’t know what’s in your modules, it’s hard to say. Generally speaking, if module A augments /b:foo/b:bar in module B, when module A is compiled, the compiler will load module B and verify that the path /foo/bar actually exists there (and refers to an augmentable node, not e.g. a leaf or leaf-list). If you then at load time get an error saying that /foo/bar in module B can’t be found, it means that the compiled B.fxs doesn’t have that node.
One possible reason is that module B was changed and the bar node was removed, but module A was not compiled with the new version of module B. Another is that B wasn’t actually changed, but a module C that removes bar via deviate not-supported is used when compiling B, but not when compiling A. Looking at your specific case, there is no node called vrf-label in the current version of ietf-network-instance (at draft-ietf-rtgwg-ni-model-12). Perhaps it existed in an earlier version, and you still have that version in the path when compiling eci-bgp-l3vpn-aug, while ietf-network-instance.fxs was compiled from the current version?
By the way, posting a followup re-asking for an answer just a few hours after posting your question might be considered bad form in a forum like this, and is in any case not likely to get you an answer any sooner.