[AT&T Samsung Galaxy S 5] AptLogic:
Really it depends on what baseband you're trying to work with. To better understand the answer I'm giving, I'm going to tell you about Samsung Knox and Qualcomm Secure Boot.

For Samsung Galaxy S devices after the S3, Samsung implemented a new security suite called Knox, which served to make devices enterprise-compatible by providing extensive anti-corruption and anti-tampering functions. One part of this was the locking of the bootloader, which is actually facilitated by Qualcomm Secure Boot, we'll get to that in a minute.

Another thing that Knox provides is this thing called Anti-Rollback Protection, which serves to prevent the exploitation of patched security flaws by defining exactly how far back the system can be downgraded. This is controlled by a thing called a qFuse (or an eFuse depending on who you ask). When you upgrade (or downgrade) to a new version of Android, the system checks that fuse value to see if it should accept the update or not. If the version's fuse value is the same as the value on the device, the update is accepted and nothing else happens. But when you upgrade to a version of Android with a higher qFuse version, the fuse on the device is "blown", and increments to that version, and the update is accepted.

If you try to downgrade lower than the fuse version, the update will fail the check, and the update will be rejected with an error saying "FAIL! (fuse x binary y)", with x representing the value on the device, and y representing the value of the update.

Now, this is a bit confusing, so I'll illustrate an example using our firmware.

The first thing you should know is that you can find the qFuse version of a firmware binary from the baseband version:

Example: G900AUCU4COI5, the qFuse version is 4

Example: G900AUCU2ANCE, the qFuse version is 2, so you would not be able to flash this over OI5.

Now, to your example, flashing a baseband from G900AUCU2ANCE over G900AUCU4BOF3, the update would not flash due to the binary's fuse value being lower than the value on the device.

And now you would ask something like "well why not just use FlashFire instead of ODIN and bypass the fuse check?" Well in theory that could work, but in practice it really doesn't, and this is where Qualcomm Secure Boot comes in.

When you flash something with FlashFire, it circumvents Knox's fuse check temporarily, and directly writes its payload to the target partition.

But both Samsung and Qualcomm foresaw something like this occurring, and they put in boot-time protections to shut that down.

When your device boots, it uses something called Chain-Of-Trust to boot the device in a sequence. It all starts with an RSA key held in a read-only part of the device. This key is used to verify the signature of every binary that comprises the bootloader, which is actually made of a whole bunch of different parts. The read-only key verifies a sub-bootloader. That sub-bootloader verifies another sub-bootloader, which verifies another part of the bootloader, and so on until you get to the application bootloader (aboot). The aboot is responsible for verifying and executing the Android Kernel, which is the first part of the system that's actually Android. Now the cool thing about the aboot is that you could break the chain of trust between it and the Kernel if the bootloader is unlocked, and the device would still boot. But since the bootloader on our devices is locked, the aboot verifies the Kernel, and then the kernel boots the system (that's right, no signature checking for the system itself, only the kernel).

That's the Qualcomm side of things, now here's where Samsung comes in, and things get a little weird.

In theory, Samsung reinforced Secure Boot further by making the bootloaders check qFuse versions along with signatures. BUT, I have seen some instances where the system allows an older kernel to boot. This is the case with NCE flasher and Safestrap, what NCE flasher does is flash the NCE kernel on the device so you can boot into Safestrap on newer versions of Android, with the requirement that you have to re-flash your old kernel before you can boot back into Android. You could in theory flash the /system partition from NCE along with the kernel, and leave everything else alone, but you would probably run into issues very quickly, mainly with the other bootloaders because they also check if the kernel has SELinux set to Enforcing, and the NCE kernel would fail the check because its SELinux is set to Permissive (you would get an error saying "KERNEL IS NOT SEANDROID ENFORCING")

TL;DR: If you wanted to flash just the kernel, it might work through FlashFire but you wouldn't be able to boot into OF3, you would have to flash the /system partition to NCE, and at that point there's not enough research to tell us what would happen next.