Basicly just a reiteration of your #1 point. I have seen containers where they create their own 'parent' containers that point to the ubuntu/debian base-image for their generic app containers. The extra layer irks me, i'd very much like to just have all app-containers depend on official containers. E.g. a project maintainer might install wget in their upstream container, then rely on that image for all its app-containers.

I think the issue there is that once you start building a number of containers, it's easy to start noticing patterns that repeats across your containers, and so it's very tempting to do what you mention to avoid repeating yourself.

I sort of agree with you, but I think it reflects a tooling problem in expanding dependencies more than anything.

After all, Docker introduces temporary images for nearly every step of the Docker file anyway, so if these "parent containers" are genuine dependencies it's beneficial to collapse the steps for individual app containers down to a set of shared ancestors as possible.

Ok. I think the issue is more transparency than layers though - for example the Hub could let you click on FROM lines and have them expand in place.