A lot of interesting ideas here. Nevertheless, I'm a bit nervous, because I hoped to see a focus on critical features missing when building larger websites, with full-fledged editorial teams (larger teams, with copy editors and editors, designers, ...).
Think about editorial flows: Of course there are already helpful parts available, e.g. ProDraft. But it would be a big help to have page versioning in core, and collision detection!
And think about teams with specialists for different work areas: Photographers and photo editors, who upload files into a central media repository and categorize them, so that editors have a logical place to search for article images, headers. To find an unique image language, sometimes with repeated use of some of the images. To publish in this way is a difficult process. Not something that could easily get replaced by AI. It's a special kind of work of human beeings, who like to be creative and want to get technical support in a way they understand and they need.
They want to have access to large galleries that they can filter. To look at their selections in a preview, that shows teasers next to the others in the area concerned. To get an impression how it works, how images works with headlines, and teasers works beside their neighbors. And publishers like to see reasons to have confidence in the scalability and further development of key features for their workflows, their cms. Therefore it seems to be important to have a, in this regard fundamental, set of key features for larger publishing teams available, in a quality and with support, that creates trust in pw as a solid and future-proof platform for larger projects.
I understand the difficulties and I know some of the arguments regarding versioning, or for one-page-one-image workarounds (against a central media management). But I'm not convinced by these arguments.
More in detail, regarding the media management question. I think the maybe best way to achieve a pw kind of a media solution wouldn't be a central, fixed media library, but to build something like a central media archive out of pages – but with multiple images per page, selectable from an image field, like images of other pages are selectable from ckeditor fields. And yes, I know that there are modules that try to offer such a solution. So maybe it's not too difficult to come to a solution in technical terms. However, it makes a difference to see such a module and such a workflow as a well known and documented way to build a reliable media management, to know it as a part of trying to establish pw as a solid alternative for building larger websites with larger teams.
Similarly regarding scalability questions. We have $config->pagefileExtendedPaths. But is that thoroughly enough tested that we can say we can definitely count on it? Does template cache work with it or not? (I wasn't able to test it out by myself.) Ryan wrote 2014: "Will have to revisit that
with a similar solution to the files at some point in the future". (https://github.com/ryancramerdesign/ProcessWire/issues/432) If we could clarify this question, that would be very good. I mean, a good thing for the ProcessWire 2018 Roadmap.
And last but not least: official NGINX support.
To be clear: I'm not concerned to criticize any contribution to the roadmap, or have anything to complain about pw. On the contrary, I hope it will be possible to advance pw. But I think it would be a good idea to focus on critical areas regarding the use of pw for larger projects, for larger editorial teams. Decisions regarding a publishing platform depends on features we can offer, but not in a simple way, that we just could show this or that functionality. More important, I think, is to give a perspective that creates confidence in serious steps to build reliable tools, to enable reliable workflows for demanding tasks of teams, i.e. to establish pw, even for more complex teams of editors and for larger websites.
This is a lesson to learn from the development of Craft. Of course, it doesn't make much sense to compare the projects, and to compare them is not my point. Success in one way or another not always depends on resources. Sometimes it's more a question of clarity and organization – sometimes success depends primarily on focusing on key issues. Although the basic requirements are very different, in many cases pw is a valuable solution right now. But it would be good to find the critical questions that the project should face, and to leave less important ones aside.
EDIT: A short note regarding the NGINX question, apart from posts in the forum there's an older, very simple attempt on howtoforge, https://www.howtoforge.com/running-processwire-on-nginx-lemp-on-debian-wheezy-ubuntu-13.04. And an article about installing pw 3.0.62 on Ubuntu 17.04/17.10 with NGINX, https://websiteforstudents.com/install-processwire-on-ubuntu-17-04-17-10-with-nginx-mariadb-and-php-support/.
Just as an example what a useful approach could look like: https://github.com/nystudio107/nginx-craft
Would be great to achieve something like that for pw, with special consideration of ProCache.