How to make a salt state on target A require a state on target B?

[unman]

I think you missed my point. Updating the menu with qvm-sync-appmenus isn’t merely unwieldy in salt. It does not work at all. The call has no effect whatsoever.

This isn’t my experience.
That said, I now set the menus using qvm.features, set menu-items,
default-menu-items
Include this as part of the clone state, and when creating qubes.

You and I did go through a discussion regarding disposable templates (I don’t recall all of the details) and were able to resolve one case, but the resolution broke other cases. I ended up…again in a script…having to either set the default menu items or menu items in a certain sequence, depending on whether a qube was a template, an (ordinary) appvm, an appvm that was a dvm template, or a named dvm, all after the qube was otherwise set up. If I didn’t handle the cases differently from each other, something would “break” and I’d have desktop shortcuts that didn’t function and/or a dvm template that didn’t show up in the menu properly.

Obviously that needs a separate thread. Perhaps this discussion should
be broken out too.

So returning to that: is it possible to make a state on target dom0 require a state on target some-template-VM, which means a state in a different sls file in a different “environment”?

It’s not a different environment - it’s all base, or user, or whatever.

I’m not clear on what you mean by “require” in this context - it’s easy
to make a state depend on the results of a state being run, by using
pillar date, or by testing for the potential outcome. Is that what you
mean?
Again, I think this warrants a separate thread: a concrete example would
be good to work with. (Not necessarily the states - an explanation of
the outcome would do.)

I never presume to speak for the Qubes team. When I comment in the Forum or in the mailing lists I speak for myself.