Interesting. I can't seem to imagine why this behaved the way it did = (looking over my config again) I am just happy that moving it fixed = the issue.

Well, unless you can come up with a configuration AND a test case that is fully reproducible, I'd rather avoid spending further time on this issue.

If the problem is related to intermixing configuration statements, then it is a bug, but it might only surface when something really odd happens (like one module mucking with some pointer somewhere and not restoring things as they should be). Then the only thing we can do is exactly track what caused this.

However, in your case, you're not actually intermixing statements, but rather sort overlays differently: all dynlist related statements exactly follow the "overlay dynlist" statement, but different overlays are ordered differently. This calls for unexpected interaction between overlays stack execution that results in the odd behavior you observed. This should be a bug as well, unless there is a good reason for having different behavior when overlays are stacked differently (e.g. an overlay legally mucks with data that is later handled by another). Again, unless you can present a clearly reproducible case, it's quite hard to track, and likely impossible if it's data dependent.

So I'm happy you solved your specific issue by rearranging the order of the overlays.

p.