As a former software engineer, I have to (politely) disagree (to an extent). (Resurrecting this thread because I’m just now tackling the same issue myself.)
The mathematics of rhythm and ratios are extremely well-understood, and this is not a new problem space with new territory to explore with every new user. We know that Dorico’s rhythm system is based on beats rather than notes; that notes are attached to positions based on a rhythm grid rather than being positioned relative to each other (while also interacting with each other in some complex ways that depend on voicing and other options); and we know that the Dorico team prefer to start new features by encoding certain sensible defaults, and then creating configurable options for users to alter those defaults in sensible and predictable ways based on stated user desires that align with the product’s direction and vision.
Given the above, the application of, say, a 12/8 time signature onto existing music in 4/4 or vice versa, with triplets, could be implemented with a single switch that applies in both directions: “Preserve rhythm relationships” or something similar. You could start by only permitting an enumerated set of conversion possibilities:
2/4 ↔ 3/8
2/4 ↔ 6/8
3/4 ↔ 3/8
3/4 ↔ 9/8
4/4 ↔ 6/8
4/4 ↔ 12/8
Some of those might mandate the “Preserve” switch to be on, or otherwise.
Application of the transform would require each note to be evaluated for a change of both grid position and duration. But for each of the mappings above, if the “Preserve” switch is on, that’s a simple arithmetic operation; if there are complex tuplets, I’d just want them preserved across the transform in either direction, occupying the same amount of the grid relative to the time signature – again, a straightforward arithmetic operation.
Difficult conversions (ie. requiring more user input to determine intent) would need more options to cover eg. Applying a 9/8 time signature to 4/4
Anything involving metreless music or irrational time signatures would be outside of the scope of this functionality, which would be strictly concerned with simple ↔ compound conversions.
Now, when I’m writing user stories for development teams, I try not to say “how” the problem I’m describing could or should be solved, because they will know best, and I don’t want to anchor their thinking. The above is a combination of what I would hope to see as a user, and some thinking out loud about implementation. (And I’ve ignored when “Preserve” is off, as that would be a huge topic to explore, and it’s 0100 where I am!)
As ever, there is a relevant XKCD: xkcd: Tasks

Right now I’m going to attempt to do my own manual conversion before going to bed. Wish me luck!