BitBake runs event handlers in an undefined order (likely determined by the recipe parse order, which is likely determined by the order files are found on disk, which means the order won't change from run to run normally, but the order is still undefined), rather than in either registration order or reverse registration order.

As a result of this, there's no way to ensure that one sanity check runs before or after another one, or one bit of ConfigParsed metadata alteration occurs before or after yours. As one example of a failure this causes, there's no way to ensure your ConfigParsed handler runs after oe_import, which means there's no way to know if oe.data has been imported, for example. As a result, many ConfigParsed handlers have to manually run oe_import(d), to hack around it, causing unnecessary work.

As another example of this sort of failure, we can't always cleanly fail out due to a missing toolchain, depending on the order in which the various toolchain event handlers run. For example, it may attempt to create the toolchain symlinks or extract the sysroot before we've confirmed that the toolchain even exists.

To fix this, bitbake should be altered to run events in registration order. I have a trivial patch implementing this (it'd be even cleaner if we required python 2.7, as we could use OrderedDict, of course), but it'll need hefty testing and buildhistory use to check for problematic event handlers. Of course, any handlers broken by that change could have broken at any time, and would just have gotten lucky regarding event handler execution order.