How does P2SH unlocking work? "Mastering Bitcoin" by Antonopoulos in its P2SH section describes how the unlocking and locking scripts are executed and evaluated by nodes. The author gives this as example of an unlocking script:

&lt;Sig1&gt; &lt;Sig2&gt; &lt;redeem-script&gt;


and the locking script:

HASH160 &lt;20-byte hash of redeem script&gt; EQUAL


Then there's this:


  The two scripts are combined in two stages. First, the redeem script is checked against the locking script to make sure the hash matches: [...]


Questions


Does that mean that not all validations follow just plain "concatenate unlocking and locking script and execute' method of validation? As a beginner I'd expect that for uniformity and security all transactions should follow this same uniform rule.  Based on the quote, it looks like the P2SH (or possibly other types) scripts are evaluated in a different manner? 
If the answer is yes, how does the Bitcoin node know which type of unlocking/locking script type should be applied for each particular transaction?
Also, if the answer is yes, are there other deviations from the plain "concatenate and execute" rule?
Say there's a very old legacy node that's not P2SH enabled. The transaction above would still evaluate to true (if the provided redeem script is right) as the stack would have   a TRUE on top at the end of execution?
Does that mean that not all validations follow just plain "concatenate unlocking and locking script and execute' method of validation? As a beginner I'd expect that for uniformity and security all transactions should follow this same uniform rule. 


Nothing uses the "concatenate unlocking and locking script and execute". That approach was abandoned in Bitcoin v0.3.7 (released in July 2010), as it was the reason for one of the two theft-enabling bugs Bitcoin had in its infancy.

The current approach is to first execute the unlocking script, look at the resulting stack, and then execute the locking script with that stack as initial stack. The resulting top stack item determines whether validation succeeded or not.


  Based on the quote, it looks like the P2SH (or possibly other types) scripts are evaluated in a different manner? 


It is not so much a different rule - just an additional rule. Because of backward compatibility, network rule upgrades can only add additional restrictions on previously-valid scripts. They can't make invalid scripts valid, as those would risk splitting the network in two (look up "softforks").


  If the answer is yes, how does the Bitcoin node know which type of unlocking/locking script type should be applied for each particular transaction?


Whenever a spend (a) validates using normal rules and (b) has a locking script that satisfies a specific pattern, defined in BIP16, an addition P2SH-specific execution follows, whose validation result is what matters.


  Also, if the answer is yes, are there other deviations from the plain "concatenate and execute" rule?


This same approach is used for a much more recent network rule improvement, called SegWit, specified in BIP141, which is expected to be activated on the network around August 22nd 2017.


  Say there's a very old legacy node that's not P2SH enabled. The transaction above would still evaluate to true (if the provided redeem script is right) as the stack would have a TRUE on top at the end of execution? 


Yes, by definition, because P2SH only adds additional restrictions. The specific P2SH locking script just checks whether the spender knows the "embedded" unlocking script (also called redeemscript).