Given we are using well-known hashing functions for passwords, i.e. SHA256, SHA512, BCrypt or, PBKDF2. Our Information Assurance SMEs have advised that we truncate the input into these hashing functions:
…to prevent the hashing function splitting it into multiple hashes.
I have not heard of hash functions doing this, in fact, I had assumed that hashing a string down with a hashing function would produce a fixed length string - am I incorrect to make this assumption?
The infamous "LANMAN hash" used in older Windows versions had a problem where it split passwords into 7 byte chunks and computed a hash for each separately. This, together with lack of salt, and other poor design decisions meant that a password of "keyboard42" and a password of "KeyBoarMint" store the same first value, making it uniquely vulnerable to a time-space tradeoff called "Rainbow tables" in which an adversary pre-calculates lots of data and then needs very little work to reverse an password hash.
Not only are the modern schemes you've mentioned proof against such attacks, even in the 1970s a competently designed password hash was not vulnerable to Rainbow tables. The advice you were given is very poor.
Even if our password hash has a fixed length output. Since passwords tend to have low entropy density. lengthening the password well past the size of the hash can still add valuable entropy.
