I would completely avoid the entire “activating packages” thing, I think for your situation there is no reason at all to ever activate either package X or Y.
Instead, the general workflow would be that you clone whichever package you want to change the compat section in somewhere locally, make that change in that folder, and then activate the main project that you started with (which is not one of the packages), then do pkg> dev PATH_TO_PACKAGE_X and pkg> dev PATH_TO_PACKAGE_Y (or whichever packages you have locally now) in the project that you are working with and then do a pkg> up. That will resolve all dependencies in the project you care about, i.e. this main project will not use the deved versions of package X and Y, and use the compat section of those deved packages to resolve all the other dependencies.
I’ve seen a ton of confusion with folks that start to work with packages about this aspect that any package is also a project and can be activated. It is one of the aspects that I wish were different in the package manager: I think a much cleaner design would be if packages had a Package.toml in their root (instead of using the same filename for package definitions and project definitions), and one simply couldn’t activate a package. Conceptually there would be a lot less overloading of terms/steps and the world would be much cleaner: there are packages, there are projects, and they are different things and there is no mix and match between these concepts.