When you're talking about a 'redeemscript' you need to be specific as to which transaction you're talking about it in.
redeemScript is a proper name. It has a single specific meaning. Scripts are limited to 520 bytes. redeemScript is always in the input of a transaction which is referencing a P2SH output of a prior transaction.
Let's say you have a transaction B, which is using as its inputs the outputs from transaction A.
In transaction A, the 'redeemscript' would be a fixed-length hash. (8 bytes? 16? I'd have to go look)
That is close but not correct. This gets a little in the weed so someone just wanting to know what redeemScript is see above.
Outputs define the terms which encumber how the output can be used, this is (poorly) named the scriptPubKey. The scriptPubKey does (normally) contain a hash but it will either be a
scriptHash or
PubKeyHash. Both are 32 bytes (SHA256 is 256 bits) but they are not the redeemScript.
scriptPubKey ("output script")Pay2PubKeyHash Tx: OP_DUP OP_HASH160
OP_EQUALVERIFY OP_CHECKSIG
Pay2ScriptHash Tx: OP_HASH160 OP_EQUAL
When technical docs refer to the redeemScript, it is referring to the script in the ScriptSig (yet another poorly named element) of the input of a transactions. There is only a redeemScript when redeeming a P2SH.
scriptSig ("input script")
Pay2PubKeyHash:
Pay2ScriptHash: ... <redeemScript>
For an input to be valid it must meet the conditions which encumber ("lock") the output. For P2SH transactions the terms are defined but unknown as a P2SH output only contains a ScriptHash. So the redeemScript is appended to the signatures in the ScriptSig. In validation the redeemScript is hashed to verify it matches the ScriptHash in the prior output. The input is then verified to ensure the signatures meet the requirements of the script.
There is no redeemScript in an input which references a Pay2PubKeyHash output. The output contains the actual script not a hash of the script. It is also possible to create other non-standard transactions which define the conditions in the actual output however those are deprecated in favor of P2SH outputs. Anything you can do directly in the output can be done in a redeemscript and the ScriptHash placed in the output. P2SH provides a better way to handle "where to put the conditions". Still the use of P2SH for almost everything except Pay2PubKeyHash kinda sticks out as this weird special exception. There is no reason it couldn't just work like any other P2SH script (i.e. address becomes not the encoded PubKeyHash but the encoded ScriptHash) then all inputs are P2SH inputs. If you wonder why we have two different ways of doing the same thing see the semi-OT side note below.
side note (just some pointless D&T pontificating):
If it seems like Pay2PubKeyHash is treated as a "special case" well it is. More generally the script can either be in the output or a hash of the script in the output (and then a copy of the script added to the input). All transactions from the most complex to the simplest could be done either way but there is no reason to have two redundant methods to accomplish the same task. The reason this exists is because P2SH didn't exist in the original Bitcoin. Outputs (even for "sending coins to an address") are always scripts. It works for simple scripts but more complex scripts become clunky as the sender needs to know the entire script not just which key to use. Providing the sender with a hash of the script is superior for a lot of reasons. It is a good separation of concerns. So Bitcoin was forked to support P2SH. Technically support for Pay2PubKeyHash outputs could have been removed (you can generate a P2SH address for a single key script) but it wasn't. Support for having the output contain the script remained (primarily to support "normal" Pay2PubKeyHash transactions). It is very likely that P2SH will eventually replace all other transactions leaving only Pay2PubKeyHash which defines the script in the output making it a special exception in practice if not protocol.
If Satoshi had thought of P2SH from the beginning it could have eliminated the redundancy of having scripts in both input and output. P2SH is normally used for complex scripts but there is no reason a very simple script like OP_CHECKSIG can't be used. Instead of providing the sender an address which decodes to the PubKeyHash (and then the client knows to stick it into a special output script) you would provide the sender an address that decodes the the hash of this simple script. You can use it right now for your existing keys - it will produce a different address for the same key though*. If an altcoin supported this from day zero then the output could be simplified further. There would be no need for any opcodes in the output. They would just contain the script hash. This would not only make transactions smaller it would more importantly reduce the size of the UXTO.
* Warning: Any time you work with custom scripts always use testnet. You can permanently lose funds due to invalid or misformatted scripts.
