So I finally got around to actually starting on this project, which requires mixing data from two seperate source system schemas.
What I can say is this (so far) - seperating views out by their respective source system schemas will work. However, what I am seeing is some AWFUL performance. What I see happening through VizPlan is that essentially the entire result from each view needs to be materialized and THEN the join occurs. So instead of the various reduction phases being able to work their magic and optimize the joins, we have to wait until afterwards to do a massive join.
To make things ultra simple, consider the following example. Testing on a rev 74 box.
Required end result query (Super Simplified), running in Studio
SELECT A.COL1, B.COL2
FROM SCHEMA1.TABLE1 A
INNER JOIN
SCHEMA1.TABLE2 B
ON (A.COL1 = B.COL1)
WHERE A.TYPE = TEST_TYPE
We would see a VizPlan that resembles somehing like this, with execution time of aroun 8 seconds and output
To accomplish the same thing, we would have to create two views, one that encapsulates each of the schema views.
VIEW1 = SELECT COL1 FROM SCHEMA1.TABLE1 WHERE TYPE = 'TEST_TYPE"
VIEW2 = SELECT COL1, COL2 FROM SCHEMA2.TABLE2
End View
SELECT A.COL1, B.COL2
FROM VIEW1 A
INNER JOIN
VIEW2 B
ON (A.COL1 = B.COL1)
So here, when we execute we get a VizPlan like this, and the total runtime is over 2m30s. We can see that the entire results of both views are materialized first, and THEN the join is happening. Obviously this requires a huge chunk of temporary processing, whereas a query that is able to optimize knowing the tables "natively" has a huge advantage to reduce the data size before the join ever occurs.
Keep in mind this is using scripted calc views, I am not sure how (or if) this behavior can change using graphical calc views - but my guess is that it won't really since similar operations need to be performed.
Another idea to retain the first style of SQL syntax (directly referencing tables and not views), is to use synonyms for these tables across all systems that the content may be migrated to. Obviously, this would impose some additional work, but would allow the tables that exist in different schemas to be referenced and joined in the same view, achieving ideal optimization.
I'm sure someone has already hit this issue - so opening the thread back up 
Happy HANA,
Justin