I'd say that after the launch of Github wikis/Pages, using READMEs as anything but a quick project overview is a regression rather than an evolution.

Sure, you can put a bunch of quick links in there to get people started, but as a potential user interested in using a project, I'm not interested in your complete overview of the source code architecture or the necessary onboarding steps.

Put a quick link in the README to guide people to the right place, but don't put all of your project documentation in there unless your project is particularly small. We've grown beyond storing a bunch of texts files in a SVN respository, every major source control system also has a way to document your project.

If you choose to keep your documentation inside of your source control, the rise of Markdown viewers that support navigating links can help you achieve the same benefits by just linking to docs/project-overview.md in the top of your README.

> The times should reflect this evolving need.

There's no need since, these needs are already addressed in their own files for decades IMHO.

Readme files are a general map most of the time. Other relevant files are "Install", "Contributing", etc. Your README should be concise and refer to another text (or markdown) files in the repository.

Of course people adapt and evolve but, I don't understand the attitude of "We've just invented this". No, we didn't. README.1st, CONTRIBUTING files are as old as computing now.

They can be both. I actually like markdown for collaborative team documents because they are so simple. I’d rather people focus on the content rather than trying to make the perfect PowerPoint or format a word doc or something.

I also like that the on-ramp document can get PRs from new hires who find some improvement, etc etc.

Those things are deserving of being explained, but do they really need to be in a readme? Can't we just link to them?