Modules you should be using (instead of some popular counterparts) because they will be in Drupal 8 Core.

Seven theme is a special case that has to cover a lot of ground: It has to be completely accessible Mobile friendly Provide consistency across 20.000 modules Stand the test of time – as it is often the main way people interact with Drupal and one of the main ways people come to understand the Drupal brand. This is a proposal, so we hope to receive loads of feedback.

Drupal finally began replacing NIH with PIE. Compare Drupal's 8.x branch a year ago with it today. A year ago, we had one class of 3rd party PHP code, in an uninteresting corner of the update system. Today, it contains 3rd party code from no less than five different projects: Symfony, Doctrine, Guzzle, Assetic, and Twig. Those libraries are included via Composer, the new and ground-breaking PHP-library-management-system-that-actually-finally-works. Code from at least one more should be landing soon.

Everyone agrees menu links should be entities. Jury is out on Menus => Let us do menu links to start with and that will inform subsequent thought. We can, nevertheless, say that the original idea of menus as bundles of menu links is off the table.

I believe as fago is currently using the terms:
Property: A compound data element on an Entity (basically what we call "Fields" in Drupal 7).
Field: A special case of a Property that is user-added rather than defined by the module that declares the Entity type.

When I look through these two lists I see a lot that is developer focused. Better internal and external APIs are definitely targeted at developers and those are 2 of the 11 goals for Drupal 7. When it comes to Drupal 8 configuration management and web services are both things that have a definite impact on coders. The html 5 initiative was for front end developers. Without even digging down into these initiatives I can see a top down approach of developers as a target audience.