My 2c worth.
## Consolidated Code Repository
I personally don't think this is optimum. While, sure, it makes checking out the Framework easy, it does complicate matters.
It doesn't promote isolation of the code (we've had cases where tests passed in the full stack, but didn't on an individual package because some test scaffolding bled into other tests).
It makes the tests for each package longer to run (if I want to make a quick fix to Keychain, I have to wait for all the other tests to run first).
It doesn't allow for incremental changes to individual packages to happen when they are needed (for example, many packages could go 2.0 right now, but it's not happening because some packages are not quite ready).
My personal preference, and it's come from working in both the Composer and NPM universes, is that individual package are the point of truth, manage their own dependencies (the less the better) and their own lifecycle (some packages will get a lot of support and change a lot, some won't - so be it).
In terms of being able to download the whole Framework, this can be done with Composer's create-project feature. In fact, you don't want to do that at all. You want to spin up a half-dozen examples of starter applications (command line, REST, web site, et al) that people can pull down and have a skeleton application up-and-running very quickly.
Given the previous comment, I feel strongly that documentation should still live with each package.
However, the intention was always so be able to build the programmers API into one site (from the DocBlocks), and also compile all of the package documentation into one master site (something like what Laravel does would be what I would aim for).
The advantage of leaving the docs in the same repo as the code is that you only need one pull request to check that the documentation has been adjusted appropriately for any given code change.
To put it another way, it's easy to automated collecting docs from several sources. It's not easy to automate checks that there is a PR for code (and tests), and a PR for docs. The split strategy has never, ever worked for the CMS, but having docs and code in one contributor PR has worked in the Framework for many years.
## Minimum Supported PHP Version
I think each package should be able to govern what it needs as a minimum version, and 5.4/5.5 should be allowed on merit.
## Package Specific Goals
I've actually been thinking lately that a Cache is just a storage layer, and that this can be combined with the Database abstraction layer.
I really question whether this is necessary any more. At it's heart, it's really just a storage adapter.
This needs a lot of work and split into several packages: data validation and HTML form building.
I'd love to see Language converted to an adapter pattern so the the API can use any sort of language file/storage format, not just the Joomla .ini definition. It would then be a good candidate for a PSR.
This is a bit of a cross-over comment, but I think it would be a good exercise to implement Monolog in the CMS, and build out a legacy JLog interface layer.
To be honest, I think that strategy should be used more and more to replace all the old junk in the CMS.
That will do for now :)