This seems like a good thing overall, so long as care is taken
that Gradle allows the user to see a master table of all the
props and gives guidance to those who want to create their
own props in the future.

It would be a painful if every time someone wanted to add a
new plugin, the shortcut convention risked clobbering
custom props that occupy the same name.

Shorter is better & enhances readability... but there must be some
idiom in place to ensure predictability with regard to custom prop
names & future plugin shortcut names.

Obviously, whatever shortcut mechanism is used for java plugin
prop names should also be used on all other plugin prop names too,
automagically (so nobody forgets to create the shortcuts when they
add a new plugin).

This is an important issue. It is about namespaces with regard to predictability and readabilty.

Right now you have two ways to access the propery of a plugin convention. Either convention.plugins.java.someProp or someProp. In the case of the latter, if there is a name conflict with another plugin, it is undefined which plugin wins. There have been also complaints from users about readability. For example:

sourceCompatibilty = 1.5

How do you know whether sourceCompatibilty is a local script variable or a convention property. This is hard to figure out.

So my tendency is to ditch non namespace access to covention properties and only allow java.sourceCompatibilty or the lengthy stuff above. We must make sure that plugin identifiers are unique and predictable. We should discuss this one the dev list.

My current opinion is that we should provide non-namespace access as well as namespaced access.

java.sourceCompatibility or sourceCompatibility

There are good use cases for both notations.

We should also support closure style configuration, such as:

java {
   sourceCompatibility = 1.5
}

It might make sense to support map style configuration, too.

Can we close this, now we have extensions?

Yes.