Your VB code is leveraging the feature of a default form instance.
(In VB.NET) Behind the scenes each of the Form classes is given a static variable of the same type as the form itself, and when a new form is created it sets itself as that static variable's value. That variable is also the default static property of that type (another feature that VB has that C# does not) which is why you can use the type name to directly access this property. You can see this related question for a bit of history as to why this feature still exists in VB, despite the fact that it doesn't strictly make sense any more.
There are ways of mostly replicating this behavior in C#, creating the static property yourself and setting/clearing it manually, but I strongly discourage you from doing so. This general concept is rather poor practice, which is why this feature was intentionally omitted in C#.
There isn't conceptually just a single instance of forms, even if some of the forms that you use my happen to only exist once.
A more preferred practice would be to create an event in your second form that the first form subscribes to. (Or uses an existing event, if appropriate). In this case you want to have the parent form have Enabled
set to false whenever the child form sets it's Enabled to true, you can do this through the use of an existing event.
When you create your child form, from within the parent, just use the EnableChanged
event to change the parent's property based on the child's actions:
Form2 child = new Form2();
child.EnabledChanged += (s, args) => Enabled = !child.Enabled;
Then the child form never needs to know anything about it's parent. This is fantastic from a design perspective. You reduce coupling, and improve modularity. The developer of the child form doesn't need to know anything about the parent form or what it needs to do. The child form just needs to know how anyone might want to use it and provide the needed functionality.