Hi Peter,
There are definitely some issues with the Papyrus release engineering. This is a big topic for a big project with many branches and repos (Bug/Feature branches, Component repos, Maintenance/Release branches...), plus many jobs (Build, test, gerrit, ...) with various stabilities (Nightly, release...). It's easy to get lost and miss some cases.
So there really are some issues. The build trigger times are supposed to be different between release versions (Oxygen vs Photon), but I guess it was an overlook when the Job was cloned to prepare the Photon branch. It shouldn't be difficult to fix.
Regarding the version schemes, that's also a complex topic, where the tooling doesn't scale very well (Especially for the Papyrus project, which initially didn't follow the API Tools convention during its incubation phase - and we realized a little bit late that if you don't follow these conventions from Day 1, it's pretty much impossible to get proper API management without refactoring the entire code base later on)
So Papyrus versioning is not perfect, and unfortunately won't be easily fixed.
I've had a look at the Version Numbering guidelines, and they seem to work well with the older Release Train schema, where we shipped Service Releases several times a year, and only one minor or major release a year. Since we now moved to Minor Releases scheme (Oxygen.1 instead of Oxygen SR1), we'd have to ship Papyrus 3.100 for Photon and Papyrus 3.x for Oxygen (Assuming we don't get any API break between Oxygen releases). And I don't think that API Tools would help maintaining these versions either - IIRC, it doesn't handle service segments at all, so many patches that don't affect the API are checked in without any version change.
For a project of this scale, it's nearly impossible to provide good versioning without perfect tool support - and unfortunately the tools that are configured today are not perfect, and would - at least - require a complete refactoring of Papyrus packages.
Cheers,
Camille