I've created a zip file with some
supporting documentation for this one. It includes a web part which puts a whole bunch of debugging info into the page content as an HTML comment.
The problem: when you create a linked document pointing to a page, the properties of the original page change. For example, CMSContext.CurrentPageInfo.NodeId no longer reflects the ID of the original page, but of the linked document. CMSContext.CurrentAliasPath also changes to reflect the alias path of the link, not the original.
If you change anything on the original page and republish it, even more properties change for the worse.
However, if you add a new alias to the original page and check the properties at the alias's URL, the properties are correct. That is, they are what they should be for the original page.
This affects any web parts which base their behavior on properties of the current page in CMSContext.CurrentPageInfo or CMSContext.CurrentDocument, and possibly other areas. It explains a bug I've seen in the breadcrumbs, and some other bugs we were encountering with web parts we wrote.
I can't think of any reason that this might be desirable behavior--it makes it impossible to get information about the original document that a linked document points to, using the API. You could probably write something which searched the db directly, looking for the object which corresponds to the URL in the address bar, I suppose, but that would be extremely inefficient, and why should you do that when the API's supposed to have helpers for stuff like that?
To reproduce this condition, see the README.txt contained in the zip file linked above. There should also be sufficient examples of what's changing and when contained in the .txt files. To see the condition for yourself, install the web part contained in the zip file, put it in a page layout, and view the source of a page before and after creating a linked document pointing to it.
If you need further details, I am happy to provide them. This is a show-stopping bug for us, in that we can't write a number of web parts until we can rely on the API delivering correct information about the current page.