I am trying to connect some web parts across different pages (in the same site) and the behavior I am seeing doesn't make sense to me. I think I am missing something in my understanding.

I am using SharePoint 2010 and SharePoint designer to attempt this.

My ultimate goal is to have a page with a web part that provides report parameters on it, then connect that to a SSRS ReportViewer web part on another page.

Because I could not get that working, I started to just try to connect various filter web parts to things like document library views.

What I have noticed is that when web parts are on the same page, the option to Connect to a Web Part on this Page is always available.

But most of the time, the option to "Connect to a Web Part on another page in this Web" is grey'ed out (unavailable) for me.

I am trying to figure out how SPD figures out that other web parts are "available" on other pages and have the right input types (i.e. they can take the output of a filter web part as input).

I got it to work once, by creating fresh web part pages, and using simple built-in web parts, but I can't seem to make it work predictably and I can't seem to make it work at all with the ReportViewer web part on another page. (it does work when on the same page though). Are there specific permissions needed to do the cross-page connection?

Only if these conditions are satisfied will SharePoint Designer let you pick "Connect to a Web Part on another page in this web" and that's not the case for any OOTB filter web parts

What does obsolete mean in this context?
Prior to SharePoint 2007 it was SharePoint which had "invented" and implemented Web Parts, but with ASP.NET 2.0 the ASP.NET team made their implementation of Web Parts, which SharePoint 2007 then inherited. The ASP.NET Team made some changes to how Web Parts was implemented and one of the areas where they made most changes was in the area of Web Part Connection, which they made a lot simpler, but in that simplification the way SharePoint had implemented Cross Page Connections was lost.
When the SharePoint team inherited the ASP.NET Web Parts, they made a Web Part class which was backwards compatible, but much of it was marked as obsolete, to tell developers, that this functionality may be removed in a future SharePoint version.
Most developers (including Microsoft) has then decided not to use the obsolete marked SharePoint specific parts when implementing new Web Parts.

Why does SharePoint Designer have support if it's obsolete?
Because it being marked obsolete doesn't mean it doesn't work, and there are still some Web Parts which is implemented with the functionality, so support for using that the functionality in Web Part pages is still in SharePoint Designer.

What can I do if I want similar fuctionality, but my Web Parts doesn't support it?
One way to implement something similar is to use a Query String (URL) Filter Web Part on the "target" page which can then get the connection info as part of QueryString for the Page request. On the "source" page you then have to add some Web Part which will redirect to the "target" page with the right query string when it gets a value from the "source" web part. Unfortunately I don't think a standard implementation of that Web Part exists, but it shouldn't be that hard to develop. A lot of this can be taken from Nikhil Kothari's old blog entry WebParts and Cross-Page Connections

So support for Cross-page connections are supported in SharePoint Designer 2010, but obsolete after SharePoint 2003?
–
lwbecker2Jul 25 '12 at 2:26

Actually I think it became obsolete in SP2010, but I might be wrong
–
Anders RaskJul 25 '12 at 7:13

I've added a lot to the answer about what obsolete means in this context and a possible work around
–
Per JakobsenJul 25 '12 at 11:07

Thanks for the clarifications. Re: the work-around with the QueryString (URL) filter, I am trying to hide the parameters being passed from being in plain view by the users, who may be tempted to edit the parameters that are visible in the URL to access other information.
–
lwbecker2Jul 25 '12 at 14:06

In that case I think you have to either: Create own Web part supporting cross page connections or create a pair of Web Parts doing inpage connections, redirect and communicate through cookie, session state or obfuscated QueryString
–
Per JakobsenJul 25 '12 at 15:56