If you are free to choose a hash function, you are free to truncate SHA-512. Truncated SHA-512 is secure, there is no need to wait to see it used in a standardized protocol to increase confidence in its security.

Creating a truncate(SHA-512, 256) out of regular SHA-512 is trivial, so it true that it is widely supported nearly everywhere.

This is wrong, SHA-512/256 is not the same as calculating the output of SHA-512 and then taking the first 256 bits of it, there are some differences between them such as different IVs that would make the outputs also different.

Yes, sorry. You need to overwrite the initial value (H0) too, in the constructor. You can do that if you can touch the equivalent of the private member variables.

    SHA-512/256 may be used to hash a message, M, having a length of 𝓁 bits, where 128 0 ≤ 𝓁 < 2.
    The algorithm is defined in the exact same manner as SHA-512 (Sec. 6.4), with the following two exceptions:
    1. The initial hash value, H(0), shall be set as specified in Sec. 5.3.6.2; and
    2. The 256-bit message digest is obtained by truncating the final hash value, H(N), to its left-most 256 bits.

(from §6.7 in http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4....)

EDIT: I trust 'tptacek (in sibling comment) that if there is no chance of protocol confusion, there is no advantage to the different initial value.

This only matters if there's an existing protocol that uses truncated SHA-2 you need to interoperate with (and your premise is there is not).

There is no functional advantage to having a different IV for SHA-2 5-2/256.

Yup, this looks like it's a cross-domain protection.

Sure, but if you care about domain separation, you can't rely on the IV anyways.