Most of what you ask about doesn't have anything to do with Version Bits actually. :)

Let's start from the top:

nVersion is a four byte (32 bit) field in the block header. The version field was first interpreted as an integer with the genesis block introducing version 1. Later the network was softforked to create blocks of version two. From that point on it was required that all blocks have a version number equal or bigger than two. Expressed in binary, two is 0010. Since the version field is little-endian, this meant that going forward it was thus required that the first three bits in the version field had to be 001.

BIP0009: Version Bits introduced the idea of interpreting the remaining 29 bits as flags instead of interpreting the whole field as one integer. Readiness for a softfork proposal is expressed by setting the respective bit to 1 in the block. (More rules for using Version Bits are specified in BIP0009.) It is thus possible to signal readiness for up to 29 softfork proposals at the same time. Therefore each Version Bits field corresponds to signaling about all softforks currently in deployment.

Out of the proposals you list, only SegWit uses Version Bits for deployment: List of version bit deployments. None of the other mentioned proposals is a softfork, and they don't make use of Version Bits for deployment. Instead, they communicate support by setting the Coinbase text.

Most of what you ask about doesn't have anything to do with Version Bits actually. :)

Let's start from the top:

nVersion is a four byte (32 bit) field in the block header. The version field was first interpreted as an integer with the genesis block introducing version 1. Later the network was softforked to create blocks of version two. From that point on it was required that all blocks have a version number equal or bigger than two. Expressed in binary, two is 0010. Since the version field is little-endian, this meant that going forward it was thus required that the first three bits in the version field had to be 001.

BIP0009: Version Bits introduced the idea of interpreting the remaining 29 bits as flags instead of interpreting the whole field as one integer. It's also less of a vote but rather a signal of readiness for a softfork proposal. The readiness is expressed by setting the respective bit to 1 in the version field. (More rules for using Version Bits are specified in BIP0009.) It is thus possible to signal readiness for up to 29 softfork proposals at the same time. Therefore each Version Bits field corresponds to signaling about all softforks currently in deployment.

Out of the proposals you list, only SegWit uses Version Bits for deployment: List of version bit deployments. None of the other mentioned proposals is a softfork, and they don't make use of Version Bits for deployment. Instead, they communicate support by setting the Coinbase text.

Most of what you ask about doesn't have anything to do with Version Bits actually. :)

Let's start from the top:

nVersion is a four byte (32 bit) field in the block header. The version field was first interpreted as an integer with the genesis block introducing version 1. Later the network was softforked to create blocks of version two. From that point on it was required that all blocks have a version number equal or bigger than two. Expressed in binary, two is 0010. Since the version field is little-endian, this meant that going forward it was thus required that the first three bits in the version field had to be 001.

BIP0009: Version Bits introduced the idea of interpreting the remaining 29 bits as flags instead of interpreting the whole field as one integer. Readiness for a softfork proposal is expressed by setting the respective bit to 1 in the block. (More rules for using Version Bits are specified in BIP0009.) It is thus possible to vote on up to 29 softfork proposals at the same time. Therefore each vote corresponds to all softforks currently in deployment.

Out of the proposals you list, only SegWit uses Version Bits for deployment: List of version bit deployments. None of the other mentioned proposals is a softfork, and they don't make use of Version Bits for deployment. Instead, they communicate support by setting the Coinbase text.

Most of what you ask about doesn't have anything to do with Version Bits actually. :)

Let's start from the top:

nVersion is a four byte (32 bit) field in the block header. The version field was first interpreted as an integer with the genesis block introducing version 1. Later the network was softforked to create blocks of version two. From that point on it was required that all blocks have a version number equal or bigger than two. Expressed in binary, two is 0010. Since the version field is little-endian, this meant that going forward it was thus required that the first three bits in the version field had to be 001.

BIP0009: Version Bits introduced the idea of interpreting the remaining 29 bits as flags instead of interpreting the whole field as one integer. Readiness for a softfork proposal is expressed by setting the respective bit to 1 in the block. (More rules for using Version Bits are specified in BIP0009.) It is thus possible to signal readiness for up to 29 softfork proposals at the same time. Therefore each Version Bits field corresponds to signaling about all softforks currently in deployment.

Out of the proposals you list, only SegWit uses Version Bits for deployment: List of version bit deployments. None of the other mentioned proposals is a softfork, and they don't make use of Version Bits for deployment. Instead, they communicate support by setting the Coinbase text.