And also a great risk of creating corrupt ROMs if you're careless. Flips is primarily designed for clueless noobs who can't be trusted to know how to answer such a question correctly. Noobs don't know the CLI exists, so I hid the unsafe options there; it's the best compromise I could think of. But yes, it does suck for people who know what they're doing.

I believe the best solution is updating the patch on your side. This way, your users will get proper errors if they apply the MSU patch to wrong ROM (for example if they forgot patching SA-1), and also a reasonable guarantee that the patch has been tested and still works.

For some patch merging tasks, the correct answer would be a mode that applies multiple patches to the same ROM, then merges the differences. This would ask noobs fewer confusing questions, give proper errors (rather than a corrupt ROM) if the patch is not intended for that ROM or if two patches change the same byte, and a few other advantages.

But in this case, the MSU patch builds on SA-1; the patch merger would see a few bytes changed by both, and would complain. I guess it's possible to create a patch from SA-1 v1.6 to v1.7, then use v1.6 as base and pass v1.7 and MSU-1 to a multi-applier, but that's deep into 'can't see the forest for the trees' territory.

Unfortunately, Flips is deep into maintenance-only mode. I don't have enough motivation to implement a patch merger, a checksum question, or any other new functionality.

Ok, I see... thanks for your reply :)
I guess the best compromise is then to have a bps to patch the original with msu, and an ips for the versions that are intented to get merged with another patch. It's much maintainance to update each msu hack everytime somebody updates a patch to be merged with.