Should the Policy to Miniscript compiler(s) be considered as deterministic and is this the end goal?

The mapping between Miniscript and Script will never change. (At least, not without a major version bump of this library and at this point, probably a "Miniscript 2" which is billed as a different language.)

The mapping from Policy to Miniscript may change even between successive runs of the compiler. Currently, the Miniscript compiler produces the most optimal compilation in terms of average satisfaction costs but the compiler internal uses non-deterministic HashMap traversal. It might produce two different compilations of the same average satisfaction cost. So it is not advised to rely on the Policy compiler producing the same results. Even the C++ and Rust implementations may differ in actual Miniscripts but will have same average satisfaction costs.

In the future the compiler could be improved and Miniscript extended. In addition there may be auxiliary information someone has that changes the optimal script but doesn't fit in the currently accepted Policy compiler. Policy language and the current compiler should be seen as a demo and not the final authority on declarations of Miniscript. The real value of Miniscript comes with being able to reason about arbitrary scripts that people give you regardless of how they came up with them. If you reduce that to needing the Policies they were compiled from you're massively restricting its possibilities.

There is a concern that the ecosystem comes to implicitly rely on knowing Policies in this quick and dirty Policy language and a compiler can't evolve because of it. The end goal should be eventual interoperability and the the layer at which things interact should be Script/Miniscript not Policies.

This question was answered by Sanket Kanjalkar, Pieter Wuille and Andrew Poelstra on ##miniscript on IRC but has been paraphrased. Any errors are my own (and I will gladly correct).