Because this approach applies concerns across repos, it does violate some assumptions leading to undesirable outcomes.
The history accumulates and each project that adopts it gets the full history. Even a brand new project will get commits going back as far as the main history goes. As a result, cruft accumulates and multiplies across projects.
The Periodic Collapse attempts to alleviate this pressure by occasionally (rarely) collapsing the history, but this approach adds its own downsides:
Because CI instructions for “best practices” are stored in the repo, it’s not possible to supply CI instructions for both:
Best case, the tests in the skeleton repo are degenerate and pass. Worst case, the tests fail because they rely on factors expected to be supplied downstream (e.g. doc builds currently fail because they rely on the root package name being supplied to be documented).
Moreover, it’s not viable to test aspects specific to the skeleton that should not appear/apply downstream, such as to check that commit messages in the skeleton meet certain criteria.
Github has some nice features to link mentions in commits to issues and pull requests, including taking actions such as closing issues. When applying commits from the skeleton that mention fixing a common concern can unintentionally affect downstream projects unless the committer is careful to use project-absolute references (e.g. “jaraco/skeleton#27” vs. “#27”).