Several use cases iscuss different types or derivatives or artifacts. This summarises the desired identification of an artifact and how each use case can be handled.
It is possible to remove the type from the artifact identifier, leaving the id as groupId:artifactId. Should a different type be needed, the artifact ID should be changed. eg foo-webapp-1.0.war and foo-model-1.0.jar instead of foo-1.0.war, foo-1.0.jar.
The example of tag libraries where they are extra meta-information, not an artifact of their own, means that they can have a different type and be mapped to aspecific repository location. The handling of the dependency can be different because of the different type, even though its id might match that of something else.
For the use case of EJB-clients and derived artifacts, the EJB plugin would generate and install a second artifact called -client depending on its configuration. The artifactId would include the -client part and dependencies that reference it would use the extended artifactId. A copy of the POM would be made so that the client has a POM of its own (possibly modified to remove unneeded dependencies?)
For the use case of branches, this is all encapsulated in the version identifier. It may still be desired to add this to the POM for SCM handling, but as far as the artifact is concerned it uses the codebase-SNAPSHOT form for a version.
For the use case of JDK specific dependencies and platform specific dependencies, you would need to build subprojects with a different artifactId that inherited the parent. The output of each subproject can build for the different JDKs. This would need to be done on separate boxes or with a cross-compiler - easy enough to do with Java stuff by plugin properties to the compiler in the subproject POMs. This would replace the need for sourceModifications.
For the case of different formats of output (eg dist, or perhaps some sort of make replacement for native projects), the artifactId and/or extension will be modified. Even though the input is the same, the output will be different based on switches given. The plugins responsible would deploy the varied artifacts to the repository. This is very similar to the ejb client example. For a distribution where there is zip, tar.gz and exe, the type of the dependencies would be dist-zip, dist-targz, etc and the artifact Id would be foo or foo-src depending on which to use. These types are not full blown artifact types - they cannot be used as a type of the POM.
So ay derived info is a dependency only type.