As far as I know, you got the point. "Rewinding" is just the "look-ahead" strategy made possible by oracle access of the simulator to the verifier
It's usually referred to as "superpower" 'cause it's a capability a Prover hasn't during normal protocol execution, otherwise the soundness could be compromised (since the simulator can produce a convincing transcript of the interaction without knowing anything, it could impersonate a cheating prover pretending to prove a false statement)
Regarding the fact that simulation is exactly something verifier can do alone, that's true: the simulator has to know nothing to prove ZKness, and who is a better candidate than the Verifier for the role of someone who doesn't know?!
EDIT TO ANSWER FOLLOW-UP COMMENT:
In chapter 6 of Tutorials on the Foundations of Cryptography (Springer) Yehuda Lindell writes:
First, one may wonder how it is possible to “technically” rewind the verifier. In fact, when considering black-box zero knowledge, this is trivial. Specifically, the simulator is given oracle access to the next message function V*(x, z, r, ·) of the verifier. This means that it provides a transcript m' = (m1, m2, . . .) of incoming messages and receives back the next message sent when V* has input x, auxiliary input z, random tape r and incoming messages m'
so it's just the next message, not the whole resulting transcript at the end of interaction (if this was your doubt).
Given the foregoing definition of next message function (where the prover's challenge belongs to the messages previously received by the verifier) your "obvious way" seems wrong to me for a generic (aka potentially cheating) verifier V*.
If the verifier is honest (so the challenge is honestly "random" - even if not necessarily uniformly distributed) you can simply revert the order in which the simulator get the messages (so first the result, then challenge, then commitment): BTW, it's the strategy to prove that Schnorr identification protocol is HVZKP (omitting -for the sake of simplicity- that we are dealing with distributions and not just actual values).
But if we have to deal with a potentially cheating verifier V* (and that's the supposed case of section 8.7 of your lecture), maybe challenges are function of commitments, so they are not mutually independent, so your best strategy is to try all results until you find the valid one (or, adopting your lecture point of view, given a result you begin trying all the commitments until the function produces the "right" challenge)... anyway you have to test a number of cases growing exponentially if you have only one degree of freedom, so a PPT Simulator cannot handle it, aka ZK is not proved:
This means that after the simulator rewinds, it is as if the entire protocol is starting again from scratch. This implies that the expected number of rewinds is exponential, and that we cannot construct a PPT simulator, implying that we cannot prove the zero-knowledge property.
So no contradiction imho between foregoing definition of rewinding and the conclusion of first paragraph in section 8.7 of your lecture.
I admit I haven't thought a lot about why a simulator has to be PPT and cannot -let's say- be computationally unbounded, at least in principle: I would like to hear from others about it.
In the meanwhile my educated guesses are that:
- "we consider intractable those tasks that cannot be performed by PPT machine" (Goldreich, Foundation of Cryptography Volume I pag 19)
- for any actual use, we are always constrained to use efficient entities (provers included, even if theoretically no problem to consider them unbounded)
- the existence of a simulator is a sufficient but not necessary condition for ZK, so employing this paradigm already means missing any most comprehensive assumptions: in this scenario it seems acceptable to use an overly cautelative definition