An extended comment on SAK's remarks on using Interfaces: I am including this in "answer" form, rather than "comment" form, so I can use a little high-lighting in the writing, for emphasis.
I think your continuing exposition/advocacy of using objects/classes/forms instances cast to Interfaces
as a way to partially expose/share ... to allow "access" to
... selected contents of one object/class/form by
another(s) is an important technique and concept.
Where I sometimes have trouble with the way you explain it is in your use of the word "shared" or statements like "some interface known to both forms" : for example in this thread, the OP's scenario needs only one Form to implement the Interface: the second Form can declare a public instance of it without implementing it.
For an Interface to be "known" to more than one class it usually is in its own class, independent, for example, of any Form definitions. That's best practice, imho, for future code maintainability and OO structure.
Yes, there are two other ways you can define an Interface ... outside its own class
... within the scope of either a NameSpace which happens to contain a Form class definition, or even within a Form Class definition, but use of those, imho, is confusing, and potentially a source of error: if I define an interface inside the scope of Form1's class definition, only an external form, like Form2 in this case, can inherit from it !
or ... if you locate the Interface definition in the file/Namespace that happens to include a Form ... completely outside the scope of the Form's definition
... the Form in that Namespace can, indeed, inherit, from that Interface, but this is really the exact equivalent of defining the Interface in its own class.
Particularly for newcomers here, I think it's very valuable to distinguish between circumstances in which the Interface must be implemented by a class/object/form
(a "special mode" of .NET C#'s Inheritance model, if you will), and circumstances in which an Interface definition can be used, and exactly when an instance of a object/class/Form must be cast to an Interface
I would love to see you write a full-blown CP article, with code examples of course, discussing the relative merits of the strategy of using Interfaces (perhaps focusing on the use case where they must be cast to an instance of the Interface) as a way to expose controlled access, with ideas about "best practices," and scenarios in which you would, and would not, choose this practice over the other types of strategies we so often discuss here: via events; via public static classes, via the delegate-with-static-public-instance technique I show here on this thread.
Perhaps in that article you could also explain your point about the partial class definitions and how they are valuable or relate to Interfaces, which, perhaps, I've never understood, and I suspect other people do not "get," also.
Another, wider-scope, I think, issue of interest in OO design vis-a-vis Interfaces here is ... well, let me frame it with a rhetorical question: at what point when a Class needs access to almost all the Fields, Methods, whatever, of another Class does that become a scenario best implemented by refactoring
... of some form ... like: into a base class which both classes inherit from, or by creating an Interface and passing instances of that Interface ?
As I've said before, I love thinking of work other people could do