So if you're not using Job DSL, please open a separate JIRA. If you're using the properties step in Scripted Pipeline or the parameters directive in Declarative, those do try to preserve job properties and build parameters defined outside of the pipeline, but Job DSL is still going to wipe out whatever is in the properties and parameters when it runs its seed job. Also, don't ever call properties step more than once in a pipeline - you're gonna run into a bunch of potential pitfalls there.

Annother super annoyed user here (sorry to say that, but that's just the truth).
We are setting up most of our jobs via JCasC (which wraps JobDSL) and every single time we execute our JCasC yaml files, all properties that are defined by the respective pipeline scripts are lost: parameters, triggers, sidebar links etc.
Losing parameters of jobs that are triggered not by human project members but by other systems/scripts (e.g. Pull Request Notifier for Bitbucket Server) is especially painful.
Those jobs frequently triggered by human project members will sooner or later re-receive their parameters because someone will just click "Build Now" eventually but those jobs triggered from outside will just never run (rejected because of "unknown" parameters?).
Every single time we execute our JCasC scripts we have to go through a list of jobs and "fix" them by clicking "Build Now". Yes, we could write a script for that but some jobs don't have parameters.
Instead they need to have their scm-polling re-initialized. Since some of those jobs run for many hours, so we need to abort them right away. Writing a script for all those cases feels like investing too much time on the wrong end of the problem.

I am willing to contribute a fix but where to start? What is the right approach? Should we start with an opt-in to preserve (instead of wipe) parameters, triggers etc.?

Like others have mentioned here, it would be very useful if we could append to existing properties inside a pipeline script.

We should be able to run `properties` more than once with an append option.

Should I open a separate issue specifically to track this request?

We struggled with this problem also. For now, we wrote a little script to start jobs and put it in /var/jenkins_home/init.groovy.d folder which contains groovy scripts that are executed after Jenkins docker instance started. After that, we added a stage to pipeline script of relevant job to stop it after Jenkins restarted. I know this hacky but at least works for now until this issue resolved.

Additionally, using queue function of jobDsl didn't work sometimes, so we gave up using it. It seems, there is a race condition issue.