Right now, if a plugin wants to statically analyze the AST of a Declarative Pipeline, they can use ExecutionModelAction to get the AST underneath the top-level stages section of the Pipeline, and then use ModelValidator to walk that AST node and its children. There are two problems with this approach:

1. ExecutionModelAction only stores the top-level stages, so there is no way to analyze the top-level agent, environment, options, etc.
2. ModelValidator cannot be safely consumed from other plugins if backwards-incompatible changes are going to be made in the future (as they were when matrix was added to Declarative).

I think that extending ExecutionModelAction to store the full ModelASTPipelineDef instead of just ModelASTStages is uncontroversial, as long as the change is backwards compatible.

I'm not sure about the best way to fix ModelValidator. Since the class is public, and in pipeline-model-api, my assumption was that it was intended to be a stable API. We could add an abstract implementation of that interface, and have the abstract implementation be a stable API, and add some Javadoc that indicates that the interface by itself is not stable. We could try to make the interface be stable from this point on, only adding new default methods, and never renaming or removing methods, but that might be a bit limiting.

I submitted a PR that adds the full Pipeline to ExecutionModelAction and adds an abstract implementation of the ModelValidator interface that is intended to be a public API in https://github.com/jenkinsci/pipeline-model-definition-plugin/pull/369.