Note that the PR https://github.com/vyos/vyos-1x/pull/3035 is only for 1.5 at this point: the critical question for this task is whether or not to restore the simple support for unicode.

Simple unicode support was allowed in
https://vyos.dev/T3785
however, the constraint on description, above, restricts to ascii.

The short answer is that it will change going forward, and the work within this task, and the ongoing work mentioned above will avoid failing viable configs that have the symptom of 'full section of the config not applied'; that's what we are addressing here. The longer answer above attempted to distinguish several unrelated situations that have that same symptom, and in the extreme case of a user providing a corrupted, partial, or nonsensical config, there is not much that can be divined without some user feedback and suggested debugging: if critical dependencies are missing, that means that the system would be non-operational. What interests me here is some immediate improvements that may be made, and in proceeding with that, it is necessary to make these distinctions.

Well, nothing is deleted, rather the config section is not applied if the verification steps do not pass: if the user ignores the error and warnings and saves the subsequent working configuration, the resident config.boot file will be overwritten. So I agree that it an issue for consideration, if we distinguish those cases in which this may occur, as above. Considering those cases, we can not or would not want to (1) automatically fix migration errors, in some sense or other, to avoid non-application of config sections on migration failure; bugs in the migration system should be fixed, and improvements to the migration system itself are part of the current development plans (2) support non-verified/non-existent interfaces without clarification of when if ever that is appropriate, such as the current investigation. There is current development of the design to refine the verification stage, unrelated to this specific task. Given the preceding, I would not say either that it is a case of 'everything's fine' or of 'design flaw'; design evolution is appropriate perhaps.

Config sections not applied after failed verification is not a surprise, as discussed above, though it is understandably frustrating: warnings are provided on failure and upon entering config-mode subsequent to failure, to help avoid overwriting the saved config before investigation. As we continue this discussion we should distinguish the various issues (and I will open subtasks as appropriate):
(1) missing config sections on migration need to be debugged, as with T6076, ongoing ...
(2) verification of 'late' arriving interfaces (general); configuring ZeroTier (specific): I'm looking into what may be considered for the general issue, as mentioned, and I have some initial ideas; thanks to the details provided by @L0crian I'll reproduce the specific configuration for experiment
(3) support for hotplugging interfaces: not planned at the moment, but may be discussed again for 1.5

The motivation here was from T5660, for which it was not needed. However, a version of the constructions in the branch above will be useful for development of the modern commit algorithm and comparison with the idiosyncrasies of legacy (T5492). Put on hold for now.

The configuration checks are the 'verify' stage of the respective config mode script; general structure here:
https://docs.vyos.io/en/sagitta/contributing/development.html#configuration-script-structure-and-behaviour

What is the content of
/tmp/vyos-configd-script-stdout ?

I raised this issue for discussion last week, and am testing more 'lenient' verification in cases such as above; I'll add results and plans here, as available.

PR for global solution extends the local solution in T5839:
https://github.com/vyos/vyos-1x/pull/2659

PR
https://github.com/vyos/vyos-1x/pull/2659
updated and extended for T5660.

Yes, this is only used by the GraphQL API.

Cf. the details leading to having changed this for config_op:
https://vyos.dev/T5305

After normalization of PR (compare with examples from T5939)

Forum user reports that this is resolved.

PR:
https://github.com/vyos/vyos-1x/pull/3024

Simple fix here; PR pending following tests.
https://github.com/jestabro/vyos-1x/tree/pxe-boot

This will follow from the solutions in subtask T6006.

A general summary of the issue and proposed solution to avoid for future migrations has been added to subtask T5996, however even when implemented for 1.4 it will control, but not avoid, the problem when migrating from 1.3 --- short story: this is an incompatibility between the legacy and modern parser, and a need to refine the approach towards compatibility.

@L0crian there are no changes that would allow this in 1.4-rc1 and not 1.4-rc3 but, perhaps, for a matter of timing in bringing the interface up (see below), but if you confirm that is the case and can provide the container portion of your config, I can attempt a reproducer.

The examples in T5939 reveal a general issue that, although uncommon, needs to be rationalized. The modern parser requires single backslashes to be escaped, if in quoted strings, however (1) the legacy parser (unlike the modern parser) is inconsistent in quoting values (2) the existing solution escapes all single backslashes not a part of control sequences and makes no attempt to restore single backslashes when possible --- this is safe, but leads to redundant escaping of backslashes as revealed in the examples in T5939.

This turns out to be non-trivial, due to the interaction between legacy and modern behavior; nonetheless, a simple preliminary fix is in testing, and the task will be updated with the details when the PR is complete.

This is resolved in T5923; any other related concerns, reopen or open a new task.

PR:
https://github.com/vyos/vyos-1x/pull/2941

The working implementation is linked below; performance is not yet comparable to the legacy loadFile, though there are obvious points of optimization to be made. The general framework will be submitted for PR to support other development, with load_config as an illustrative example, but not yet a replacement for loadFile.

PR:
https://github.com/vyos/vyos-1x/pull/2902

Firstly, note that this is a failure in boot configuration, and is not related to migration: the log output of vyos-router is misleading, reporting the steps following initialization. On success:
Starting VyOS router: migrate configure
on failure:
Starting VyOS router: migrate configure failed !