"SHA-256" vs "any 256 bits of SHA-512", which is more secure? In terms of security strength, Is there any difference in using the SHA-256 algorithm vs using any random 256 bits of the output of the SHA-512 algorithm?

Similarly, what is the security difference between using SHA-224 and using any random 224 bits of the SHA-256 output?
SHA-512 truncated to 256 bits is as safe as SHA-256 as far as we know. The NIST did basically that with SHA-512/256 introduced March 2012 in FIPS 180-4 (because it is faster than SHA-256 when implemented in software on many 64-bit CPUs). SHA-224 is just as safe as using 224 bits of SHA-256, because that's basically how SHA-224 is constructed. What bits are kept (provided that's fixed) is immaterial to security, but for compliance to NIST specification, the left bits shall be kept.

As stated in this other answer, in the general case of a hash function only assumed to be collision-resistant or preimage-resistant, restricting its output can make it entirely insecure. A trivial example is the 512-bit function obtained by appending 256 zeros to the output of SHA-256, which is both collision-resistant and preimage-resistant, but trivially insecure when restricted to its 256 right bits.
The stated design goal of SHA-2 functions are preimage-resistance and collision-resistance: &quot;The hash algorithms specified in this Standard are called secure because, for a given algorithm, it is computationally infeasible 1) to find a message that corresponds to a given message digest, or 2) to find two different messages that produce the same message digest&quot;. Therefore, truncation of SHA-2 functions is not playing by the book.
Update: FIPS 180-4, which defines SHA-2 functions SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224 and SHA-512/256, explicitly endorses truncation in its section 7: &quot;Some application may require a hash function with a message digest length different than those provided by the hash functions in this Standard. In such cases, a truncated message digest may be used, whereby a hash function with a larger message digest length is applied to the data to be hashed, and the resulting message digest is truncated by selecting an appropriate number of the leftmost bits&quot;.
Truncation of SHA-2 functions is safe as far as we know. That's the very principle used to construct SHA-224 from a slight variant of SHA-256, as well as SHA-384, SHA-512/224, and SHA-512/256 from a slight variant of SHA-512 (the variant being to change the internal initialization vector, in order to avoid that the output of one function reveals bits of the output of another one).
The reason why SHA-2 functions can be safely truncated is that these functions have another unstated design goal, that they reach as far as we know, which is: being computationally indistinguishable from a random function, except for having the length-extension property¹ and being that particular function. That strong property is necessary to be able to use the hash with confidence in proofs of protocols made in the Random Oracle Model, and implies collision-resistance and preimage-resistance (the reverse is not true). Truncation (by keeping any fixed subset of their output bits) of a function indistinguishable from a random function also is indistinguishable from a random function (proof sketch: any hypothetical distinguisher for the truncated function is easily converted into a distinguisher for the original function, with the same effort and advantage).
The principle can be extended to any size; e.g. SHA-512 truncated to 128 bits is, as far as we know, as fine a 128-bit hash as can be (regardless of which bits we keep), and unquestionably much preferable security-wise to MD5 (another 128-bit hash, which collision resistance is badly broken). However, collision for an $n$-bit hash can be found in about $2^{(n/2)+0.33}$ hashes, little memory, and efficient parallelization (see Parallel Collision Search with Cryptanalytic Applications). Hence for 80-bit level security (which has sometime been considered an absolute minimum in the early 2000s, and is to be considered insufficient nowadays absent argument of the contrary), when collision resistance is necessary, we should keep at least 160 bits; and when only preimage-resistance is necessary, we should keep at least 80 bits.

¹ The length-extension property is that given the bitstring $H(m)$, the bit length $\ell$ of bitstring $m$ (but not $m$ itself), and any bitstring $s$, it's possible to efficiently compute $H(m\mathbin\|r_\ell\mathbin\|s)$ where $r_\ell$ is a short, efficiently computed bitstring depending only on $\ell$. Truncation of many bits removes the length-extension property. As noted in this other answer, the length-extension property is an undesired artifact, and the basis of attacks in some contexts; and SHA-512 truncated to 256 bits is safe in such contexts, when as SHA-256 is not.