There is clear coupling between the View and Controller if you follow your "The controller holds an instance of the view, pushes variables into it, then asks the view to "render" itself." That is the concept described about. However it is not the only way. Certainly the Controller can both pass the Model to the View with no data in the Controller, and the View could instantiate the Model itself with no Controller involvement.
I don't think its necessarily coupling (or at least not high coupling). With the V and C occupying the Presentation Layer there'll always be some interaction between both unless there a third spoke to the wheel acting as an intermediary.
I really agree on getting a common terminology and avoiding the misuse of established terms. I think I've had my fill of "Two-Step View" on the Zend Framework already...
Concept: The View gets it data from the Model which is passed to it by the Controller
Concept: The View gets it data from the Model which it gets/instantiates itself
I usually call this the View-Model-Push and View-Model-Pull decision. Ad-hoc terms all

. The View-Model-Pull is captured by the View Helper Pattern (J2EE Design Pattern), but isn't a formal pattern in other references as such. I guess the Pattern really just declares an obvious implementation of the read-only link implicit in MVC between the View and Model.
I'm not aware of any formal term for the first concept above. I think it's almost taken for granted that something passes a Model to the View once its instantiated.
Your core question is: who knows how to find the Model? That is the one of the most confusing parts of MVC. In the three concepts above we get three answers:
1. The Controller knows the Model because it is the Model
2. The Controller knows the Model. The Controller probably uses the same conventions that it uses to know the View, so it creates both and gives the Model to the View. This seems to lend itself to some sort of convention based Model-View association.
3. The View knows the Model. This seems to lend itself to the programmer being able to define which Model(s) go with a View.
That leads me to:
Goal: The framework must support many types of MV associations.
Should edit "the Model" to "a Model". Unless there some really tight coupling, or the Controller is utilised at the arbitor of all Model interaction, the View in many cases will need additional Models the Controller is not aware of upfront.
To take a real life example, myself and Ralph Schindler (the ZF thing again) disagree on a few points. The result is that Ralph has created Zend_Layout - a class which relies on the dispatching of multiple Controllers in order to render multiple Views which are built into a composite output tree (and their required Models). My opposing approach, Zend_View Enhanced, completely ignores the Model under the assumption a user is capable of using View Helpers to "pull" a Model into a View mid-rendering.
I disagree with the first statement. The Controller is not the Model. The Controller may "control" the Model but the Model itself should be responsible for it's own conduct. That's the main difference between another stress line in MVC - when you have a Fat Controller (say something like Model validation and aggregation), is it time to put it on a diet and transfer the Fatness to the Model where it usually belongs?