anyonecanspend final condition of a script can be spotted just by looking at the script hash, without the redeem data? Consider the following scenario.

Alice, Carol and Bob create and fund a script with the following rules:
if now, alice pubkey, bob pubkey
else
if now+500 blocks, bob pubkey, carol pubkey
else
if now+1000 blocks, ANYONECANSPEND

The question is if anyone (besides Alice, Bob and Carol who have the redeem script) can tell by looking at the address (script hash) that its final condition is ANYONECANSPEND, and miners for example choose not to include it in a block until the last nLockTime passes and the miner can claim the entire output, not just the fee.

Based on my current understanding, just by looking at a native P2WSH address (hash of script) it tells you nothing about the redeem script, or am I wrong?

Also, can miners learn the final condition if the output is spent at its second nLockTime, like when Bob and Carol try to spend, they must also provide the redeem script, thus allowing miners to see that if they wait 500 more blocks they can claim the entire output, not just the fee, and not include it in a block until then. Thank you.
As there are no known preimage attacks on RIPEMD160 and SHA256, it is impossible to know what the contents of a redeemScript are given just the scriptHash. So yes, it is impossible to know what conditions are necessary to spend from an address given just the address. That is one of the main points of using scriptHashes: it hides the redeemScript from others until it is spent from.


  Also, can miners learn the final condition if the output is spent at its second nLockTime, like when Bob and Carol try to spend, they must also provide the redeem script, thus allowing miners to see that if they wait 500 more blocks they can claim the entire output, not just the fee, and not include it in a block until then.


Yes, this is currently a problem. If the transaction is signed and broadcast, the redeemScript will be revealed and miners could then see the ANYONECANSPEND condition in which case they may be incentivized to not let the transaction confirm. This is an issue.

However that issue is not without solution. This is specifically something that MAST (BIP 114) fixes. Basically un-visited branches in the script are hidden behind a hash. So if MAST were available and the redeemScript made use of it, then the conditions which were not used (e.g. the ANYONECANSPEND condition) would be hidden behind another hash and thus outside observers would not know about it.

Taproot is an expansion on MAST which adds further privacy by making it so that observers won't even know that there were other branches that were not used.