tobilarscheid - parsing hell, largely. Declarative is all a bundle of fun Groovy AST manipulation at its core. Initially, that was just for compile-time validation and for transformation into an intermediate JSON format for use with the Blue Ocean Pipeline Editor, but Pipeline's CPS transformations made a traditional Groovy closure-based DSL interpretation approach too painful after a while, so now we actually parse the pipeline block into an internal representation at compile time, use that internal representation for validation, and then transform that internal representation into the actual runtime model that tells us what to execute when, etc, via some janky Groovy AST manipulation.
Figuring out how to mash together the parsing, the validation, the runtime transformation, and the ability to actually specify parts of the pipeline block elsewhere and consume them as method calls/objects within the pipeline block is something I have not managed to achieve yet. I'm not averse to the idea, but I am wary of making this already overly-complex tooling even more complex, making maintainability even harder, potentially breaking existing things, etc.
Feel free to take a look at the code - https://github.com/jenkinsci/pipeline-model-definition-plugin/blob/master/pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/parser/ModelParser.groovy is probably the place to start looking. That gets called at the time that the Jenkinsfile is compiled - it does the parsing from the raw Groovy AST into the internal representation, calls the validation, and finally transforms the Groovy AST into various constructor calls so that the pipeline block actually ends up returning a https://github.com/jenkinsci/pipeline-model-definition-plugin/blob/master/pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/model/Root.groovy instance to the runtime interpreter for actual execution. It's messy. I apologize.
Oh, and as I mention in the PR, this definitely won't ever support all Declarative sections or directives. For example, anything that contains an actual step execution (so steps, post, when (in part because of when expression and in part because it'd be a pain in the ass), stage, and stages (because stage contains steps and stages contains stage) would not be supported. Nor would environment be supported. Main reason for that is because of how we handle steps and environment resolution in the AST transformation, plus that pushes even farther past what I'm comfortable with syntactically/complexity-wise than just things like options, triggers, parameters, tools, or agent.