add a posibility to extend a project by specifying it's groupId, artifactId and version

Why not just allow the specification of extend as a URL,

e.g. ${maven.repo.remote}/ant/poms/ant.1.5.3.pom

According to the specs maven.repo.remote may contain a comma separated list of URL, so this is a bad idea.
What's more you've put information about remote repo orgainzation into the path. This is also wrong because maven can be quite easily extended to work with various repo organizations (the repo might store a layout.xml file in it's root directory and the artifact fetcher would use it to build URLs relative to that root from (groupId, artifactType, artifactId, version, snapshot/release) tuples.

ok, how about:

pom:ant-1.5.3

Do you mean defining custom URL schema for refferring to artifacts
available through maven?
If we decide to do that, that notation should be also used for
declaring dependencies, right?
We would need something like that to express all the information:

maven:<groupId>/<artifactId>/<artifactType>/<version>

How would it look in practice?

<extends>maven:myproject/myproject-common/pom/1.0</extends>
...
<dependencies>
<dependency>
<location>maven:ant/ant/jar/1.5</location>
</dependency>
</dependencies>

I've just noticed a problem with the feature I've proposed (after some discussions with Norbert Pabis).

Extending a project in the current implementation involves inheriting it's maven.xml script, and there is intent to inherit project.properties file (though that doesnt' work - see MAVEN-37: the longest standing maven bug at the time of writing - over 1 year old! I hope it gets fixed by 1.0...)

Both mine original proposal, and dIon's URL variation specify the location of project.xml file only in the local repo. The two other files are not there, so this would be a regression in project inheritance functionality.

This brings us to the interesting questions: Is POM euqivalent to project.xml, or is POM composed of all three files?

In we decide for the first option, this feautre would be of pretty
limited usability, unless we extend maven to somehow know what
projects the user has checked out in source form, and thus be
able to map groupId/artifactId/version to a directory on a local disk.
This calls for some sort of registry that would have to be maintained.
A good subject for a separate discussion...

However if we decide to go down the second route, a new vehicle for POM is needed. The most straightforward solution is a zip archive that contains a file named project.xml in it's root folder, and may optionally contain maven.xml and project.properties files. The maven.xml file may include other jelly scripts and parse additional properties files, so we might allow the POM archive to contain these as well.

There is another advantage of such POM archives: - you can quickly see how a project uses Maven to build itself without downloading full source distribution or accessing their SCM system.

The POM archives would be generated by the POM plugin, and this seems to be a no-braniner task.

Loading the project from a POM archive should be reasonably easy, provided that Maven core uses URLs instead of File in a few places.

The difference between loading a local project, and a project referred
through POM archive would be parsing:

jar:file://${projectArtifact.path}!/project.xml instead of
file://${projectLocation}/project.xml

I definitly agree that POM inheritance should be declarative rather than file-based. This is a feature every organization generating multiple projects will appreciate.

not in POMv3, already in POMv4 - coming soon