The full-stack/glue distinction is very real, and can be revealed by a couple of practical tests; the best one is to ask where a bug report for a major component goes -- if it gets directed to a third-party project, then you're glue. If you handle it yourself, then you're full-stack.
Like I said, I think Django's choices are easier to justify based on development methodologies and community building, for reasons like this. It's clear who responds to bugs. Django is never stuck when they really want to make a change in something, but the upstream maintainer doesn't agree or doesn't have the same priorities. Django can provide a very concise and clear set of documentation, and activity is all centralized around one basic set of metaphors, mailing lists, bug trackers, etc. And I actually like centralized development, so I'm quite sympathetic to these arguments. (Though as a counterexample: Mozilla is a single project, and it's hardly easy to navigate as a developer.)
As an engineering principle I don't think this distinction is meaningful. That is, from an engineering perspective you can get to the same solution but with slightly different names, and based on names one solution is "full-stack" while the other is "glue". And I don't think that's a reasonable distinction to make. But of course from a mathematical/symbolic point of view names don't mean much, but for humans names do mean a lot.
Again, it's the difference between supporting code that helps other things work together, and supporting a full set of components.
But see, there you start drifting. This is not the difference. You can achieve this regardless of how the packages are laid out.
I agree that the package layout doesn't necessarily impact it (see my other reply in this thread -- it's certainly possible, for example, to be "coupled" while using third-party components, and "decoupled" while using in-house components as the default). And I still agree wholeheartedly that we don't have a good way to talk about this, because the terms that come to mind are all loaded with connotations from other things. I do think there's a clear difference in focus between Django and some of the other frameworks, though -- we are focused pretty much exclusively (partly for historical reasons and partly because of available developer time) on our single stack of components, while other frameworks focus much more on adaptability and interchangeability. And I still think that's a choice which will end up affecting every part of a framework, and that it's not possible for most projects to pull off an equal focus on both, because both routes require major investments of developer time and effort.
Yea, the Django people have a lot easier time with documentation than we do. On many mornings I find myself envying them.
Which is not to say that I'd give up the code-reuse paradigm in order to make my life writing documentation easier.