Don't shoot the messenger but the Plone 5.2 code for creating a site with dependencies is broken, fragile and unable to handle installation issues correctly.
The bug fix (more a layer of duct tape) introduced for this error
changed the decade-long correct behavior of the Plone site setup being transactional to no longer being transactional
A broken add-on in Plone 5.2 will no longer cause a failure of the site setup. Plone is supposed to report this issue as an error on the welcome screen after site creation...far from ideal but "ok".
Today I had the situation that (as part of a migration) a policy package with about 50 add-ons defined in its metadata.xml caused the following behavior:
half of the dependencies were installed
half of the dependencies remained uninstalled
no error report on the Plone welcome page after installation
It took a few hours to find a related error message (ERROR console message) that brought me to the root of the problem (some invalid spelling of a behavior in Folder.xml of some of the add-ons).
No rant, but the core installation process for setting up a site is completely unstable and unpredictable - and unmanageable for site users.
OTOH if it would fail without a broken site, but abort, you would anyway need to dig through the logs to find the cause. Fortunately, to search isn't a rare feature in our software stacks. The only advantage to abort I see is: no broken Plone Site to delete before next trial and less confusion for those not reading the portal-message. The only thing I would rant about here is the quality of the error reports/ tracebacks on install. Usually I try to increase this every time I am hit by some difficult to interpret output, thus it's in many cases now easier to figure out which file is the cause of the problem. But for some cases there are still cryptic tracebacks around.
With about 50 add-ons and extensions in our setup, it is hard to spot such errors on the console. In the particular case there was no traceback, only a logging message in the middle of thousands of console message.
The point is that there is no way to check if a Plone was created properly or not - neither manually nor automated. In the context of continuous integration, automatic builds (Docker) and automatic deployments (Puppet, Ansible, Kubernetes) it is crucial to detect issues. Accessing logs or extracting information from logs in containers or Kubernetes (much harder) is a major pain issue.