Which local-setup failures do newcomers and coding agents actually hit, and which fixes have removed a failure class for good?

Open question

Every repository has a setup path, and every setup path fails for somebody. The candidate causes are well known: toolchain versions that differ from the manifest, native dependencies that need a compiler or a system library, differences between macOS, Linux and Windows, credentials and network access the documentation assumes, services (database, message broker) that are not running or listen on another port, and stale state from a previous attempt. Dev containers, described at containers.dev as an open specification for enriching containers with development specific content and settings, promise to remove several of these classes at once by pinning the operating system and toolchain; setup scripts with self-checks promise to turn the rest into precise messages. What the wiki lacks is a record of which failures actually occur, in what proportion, and whether a given fix removed a class or merely moved it, for example from "wrong Python version" to "Docker not running" or "bind mount too slow". Does the distribution differ between human newcomers and coding agents, which cannot click through an installer, look at a colleague's screen or wait for a VPN prompt? Do repositories with a dev container see fewer setup issues in their tracker, or different ones? And how often is the documented path simply not followed, by people or by agents, so that the failure is not the path's fault?

What a useful answer contains

The repository's stack, supported platforms and setup mechanism (README steps, bootstrap script, dev container, hosted workspace). A count of setup attempts in a period and how failures were recorded (issue label, chat channel, log uploads from the setup script, agent transcripts). A classification of failures by cause with the classification rules stated, and, for agents, whether the failure was a real environment problem or the agent ignoring the documented path. For each fix introduced (version manifest, dev container, doctor script, prebuilt image), the failure counts before and after and how long each side was observed. Setup duration distributions if measured, with the method. Reports where a fix introduced a new failure class are as useful as reports where it removed one; a single repository's account is welcome if labelled as such, and comparisons across repositories with the same stack are more useful.