Hopefully I can help a little bit here, but at the end of the day I'm not sure there's a perfect workaround for this:
1) Not exactly sure why the dictionary is shared across roles, but the immediate thought that comes to mind is that if the dictionary was role-specific, it would be an absolute management nightmare for the end user. I think what you actually would want is to be able to set whether or not a property is required on a per-role basis. As you've seen, this can't be done today.
2) You can restrict a role's ability to access/modify the property dictionary via authorizations. See "blade.property" in RBAC-->Authorizations.
1. Yes, sounds like the feature request is "Global/Role local" setting for properties. Or 2 dictionaries, a global dictionary where things like intrinsic properties live and a role local dictionary. The latter may be simpler to implement?!? (And, new features not for future releases, but enhancements/fixes to currently operating versions instead are prefered.*)
2. I can't restrict their access as they need to be able to use this functionality when creating/testing new packages in Dev/QA.
So, that leaves me still with:
How do I prevent a user, who must be able to set properties, from breaking jobs in other roles by setting a new mandatory job property up?
How do I make placing a Change Control ticket number into a job's information mandatory while limiting the scope of that requirement to a single role?
The first one I don't have a solution for and the potential for intentional or accidental abuse is substantial. The second one we'll enforce by a policy requiring the ticket number be part of the job name or description and spot checking regularly for compliance.
Unfortunately our (and probably many other customers) upgrade cycle does not match the frequency of BL version releases. It has taken us a full 6 months of planning, building and incremental deployment for one upgrade. If we followed this process strictly and it only took 4-5 months I would spend 2/3 of every year working on upgrading to keep up with feature requirements. Patches/updates to current versions reduce this cycle significantly as they do not require all the porting and testing work done between revisions.