I have been testing keycloak-x (using 15.0.2 but also observing changes in master) and noticed a few distinctive changes in behaviour between X and legacy.
Multi-SPI EAR deployments seem to be incompatible with Quarkus. (We had to export the JARs within the EAR file in order for the deployments to work)
vertx (http endpoint) seems to behave slightly differently from undertow in handling the certificates. We use a custom java.security.Provider implementation (required to use a HSM) and we noticed that quarkus seems to assume keys will not change during runtime. This is not always the case. in certain scenarios (e.g. HSMs, LetsEncrypt, key lifecycle, etc) keys may change during runtime and the endpoint should be able to handle the updated TLS context. (workaround is to restart the service, which in quarkus/keycloak.x tends to take far less than wildfly).
Note a change in behaviour but worth of note:
kc.sh configwill persist the db configuration (i.e. h2-file) and setting KC_DB=new_vendor before running kc.sh start seems to be ignored.
This is a pain when CI/CD creates a docker container that is expected to be vendor agnostic (workaround is to re-run config as part of docker-entrypoint but this seems like a time waste).