3. Disambiguation. In `recipe.yml`, you refer to other recipes by the name of their directory, if you have `recipes/foo/content_editor_role` and `recipes/baz/content_editor_role`, and a recipe refers to just `content_editor_role`, which one will be applied? Sure, you could solve this by prefixing the listed recipes like `foo/content_editor_role`, but that writes a license for recipes to contain other recipes, which we specifically decided was undesirable, as outlined in point #1. An exception was carved out for Drupal core, which already does weirdo things, so it and only it is allowed to use prefixing. That's why core recipes are prefixed with `core/recipes`.
4. If you want to be able to develop multiple recipes in a single repository, you could do what Drupal CMS does and develop your recipes in a monorepo, splitting them out separately with an automated subtree split. Symfony is also developed this way, and even core uses subtree splitting for certain things.
5. This is not a closed door; it's not a priority on the recipe system's roadmap, but we might well wish to explore the idea of "cookbooks" (groups of recipes in a single namespace). So although sub-recipes are unlikely to be supported the same way modules support sub-modules, there may be some flexibility to be had here.
** How can I test Drupal CMS locally with Drupal Core's HEAD? **
Edit `project_template/composer.json`, find the `require` section and replace `drupal/core-*` with:
```
"drupal/core-composer-scaffold": "11.x-dev@dev",
"drupal/core-project-message": "11.x-dev@dev",
"drupal/core-recommended": "11.x-dev@dev",
```
Edit `dev.composer.json`, find the `require-dev` section and replace `drupal/core-dev` with:
