The problem manifests itself whenever you have a dependency trail in which not all dependencies are of the same type. However, I am struggling to find a non-war example since there are not that many types that are in use... But there is nothing in the code that specifically checks for wars, so the correct behaviour for wars is a coincidence. And it's only correct for fat wars (I'll come to that in a minute).
I still think the prolem is real, though, so I'll try to explain a bit better what I was trying to do. WAR dependencies as such are indeed not transitive, except in one case: when you want to build a slim war (that doesn't include its dependencies) and then you want to include all dependencies at the ear level. Filtering dependencies by type would allow pulling in all dependencies of type war and insert corresponding <module><web> entries in the application.xml. Similarly, all jar dependencies translate to <module><java> entries.
Also, not quite applicable at the moment as you cannot yet handle attached artefacts, but another example would be when you have an EJB client jar that has some dependencies (of type jar). As far as I understand, EJB client jars are of type 'ejb-client' in maven, not jar, so again you have a heterogeneous trail and none of those dependencies will be included.
I would expect the type filter to work on the final transitive closure of all dependencies and give me a subset that are of the specified type. Instead, it operates on dependency trails and has a side effect: not only does it apply to the dependency at the end of a trail (the one currently being considered), but it also (as a side effect) eliminates dependencies with heterogeneous trails. This feels wrong. But perhaps not... What was the original intention of supporting the type filter?
Thanks for looking at this.