Get doesn't "set" the ID Placeholder as it is already set by previous operations - either you know the Unique Identifier and provided it and can provide it equivalently in subsequent batch items or you are using the ID Placeholder in the Get itself and it remains unchanged - that is consistent - and that is the class of behaviour you are basically finding strange - it applies across all the operations which aren't constructors or search operations. It isn't hazardous any more than saying someone could put the wrong unique identifier values in batch items and get something other than what they intended - the request is well defined - the outcome is unambiguous.
That the Create Split Key operation does not use the ID Placeholder was a deliberate choice at the time. It is a constructor of objects - so it follows the same pattern as the other constructor operations - and even though it can construct based on other objects (just like Derive Key can) it also follows that pattern to not use the ID Placeholder.
On Check you need to look at the context - the ID Placeholder is used on Check - but Check itself clears it if the result of the Check would be a failure - deliberately so that it can be combined in a batch and effectively act as a conditional - only if Check passed correctly do the following operations have the required items specified.
There is no "leapfrog" going on here
Tim.