Rationale behind disallowing `hg add nestedrepo/file` to main repo?

[Roman]

Hi, for some time now (since this commit:
http://selenic.com/hg/rev/c7e8fe11f34a ) mercurial does not allow
nested repository files to be tracked in main repository, like in this
commit:

$ hg init a
$ cd a
$ hg init b
$ echo x > b/x
$ hg add b/x
abort: path 'b/x' is inside nested repo 'b'

Does anyone remember discussion about this restriction?
Does anyone can point out reasons why this is restricted?

I'm interested in making this possible in mercurial and before I began
I need to understand risks...

Why I (or someone else) might need that?

In many projects we use main repository which several reusable apps
(or 3rd party code). While I understand there is functionality of
subrepositories I'd very much like to be able to track whole CODE from
given project in ONE repository:

- sometimes reusable code from nested repository requires additional
files - not tracked inside nested repository* but it should be
definitely tracked in "project repo",
- in several cases reusable apps are taken from 3rd party repository
hubs like bitbucket, whilst some of our tools (like continuous
integration tools) do not have access outside intranet - and even if
they had, those hubs rarely have "availability" issues which would
cause false-failures**,
- our production package bundler should not depend on anything else
than intranet hosted "project repositories",
- it'd be better to see whole changeset as one instead of having to
check 3rd party repositories diffs...

* not tracked in nested repository for at least one reason: read-only
access to it, sure one could clone it add some branch and add needed
files, but it impacts productivity, clone means merging work on
updates,
** surely we could host clone of every posible app in our space, but
again, it adds unnecessary work and (at least seems like) that it'd be
easier to make it possible within mercurial without need of additional
clones/branches...

regards
-- 
Roman Barczyński