As far as I can tell, that works as designed.

I don't think all of the effects are documented. I have been looking into this for a while and I am still often surprised about what I see. I think that in general user expectations about miracles RTC planning should be able to do is exceeding what real capabilities can be made available by far.

In addition the question here is so oversimplifying that it does not even make any sense to try to answer it see my favorite How should I ask a question in the Forum if I want to receive useful answers?. The answer already triples the amount of data in the question.

Documentation, there is the product documentation, there are articles about how things work and we have added information in the Wikis. If you really read the documentation you will be able to find a lot (e.g. that parent child rollup is not supported across project areas. But who really reads it anyway? The articles add details about what works and how to use it.

Here what we did for multi repository stuff. https://jazz.net/wiki/bin/view/Deployment/PlanForMultipleJazzAppInstances . There is a wee bit on planning.

In general what you should expect (with planning, again oversimplifying).

A plan lives in a project area. The plan should be able to display the work items from that project area. It should be able to show parent child relationships between work items in that project area. It should allow to modify attributes of project areas that live in this project area.

If plans show work items from different project areas, be happy.
If plans allow to modify attributes for work items in other project areas (including link creation), be happy. Don't expect it to be possible.
If plans (like cross project plans) show work items from other project areas in other repositories, be happy and do not expect to be able to change the remote items in that plan.  

To be able to change work items in other project areas and even in other repositories, the specifications like OSLC would have to make it easy to delegate display and modify operations, which they don't. Or the planning component would have to make a lot of risky assumptions, manage all the different data specifications and handle all the delegation operations. This is just not happening. The OSLC link "Tracks/contributes To" for example does not even have to have work items on the ends. It can be an (OSLC) change request and that would not even have to support the state concept or any other concepts and attribute types work items support.

The cross project planning is made to be able to manage items in your project area and to be able to get a visualization for the plan items and their execution schedule on the other end. To keep the complexity and performance impacts low, you can only see very few information and not even look into the link relationships on the remote end. Performance considerations also limit what other plans support.

One thing you should not expect a lot about is what you can not do. It is practically impossible to document what you can not do. The amount of things you can not do is infinite.

Like Ralph, my understanding is that this is not supported.   You certainly could submit an enhancement request for this functionality, but you'd want to provide compelling reasons why it is important to your organization that this be done in the context of the plan, rather than navigating to the target repository, since cross repository operations are usually expensive to implement efficiently.