YES, PLEASE. This is quite a headache when trying to re-use the same checks in package_id and elsewhere. self.settings and self.options should not be modifiable in package_id(), but it would be great to be able to do read-only access to these values as mentioned in the issue.

Doing valid_max_cppstd(self.info, "14") can be used in the above snippet as a workaround, though.

@jcar87 I am checking this based on my PR #16456 because it is a bit dirty.

I am thinking that:

if self.info.settings.get_safe("compiler.cppstd") and not valid_max_cppstd(self, "14"):
     self.info.settings.compiler.cppstd = "14"

in the package_id() doesn't make a lot of sense anymore. With the new compatibility() method and the compatibility plugin the original information used to create the binary can be respected and maintained (otherwise the above produces information erasure) while the desired binary compatibility can be defined.

def generate():
        cppstd = self.settings.get_safe("compiler.cppstd")
        if cppstd and not valid_max_cppstd(self, "14"):
            tc.cache_variables["CMAKE_CXX_STANDARD"] = "14"

This wouldn't be aligned with the general strategy in ConanCenter packages @jcar87. This is overwriting and hardcoding defining settings, why many recipes do raise a validate() if my compiler.cppstd is not at least 17, and there would be other recipes that can ignore that and build with an hardcoded different cppstd than the defined one without even notifying users.

This has been solved with the approach in #16871

The solution is to allow the --build=compatible new policy to be able to build a compatible one, instead of using a non correct cppstd information inpackage_id or forcing the cppstd value inside the recipe.

The above practices, doing tc.cache_variables["CMAKE_CXX_STANDARD"] = "14" and self.info.settings.compiler.cppstd = "14" in recipes are discouraged.