BOOL datatype feels weird

[lucasbalieiro]

if we read the documentation for the BOOL datatype, it states:

Boolean value. Encoded as an unsigned 1-bit integer, True = 1, False = 0 with 7 additional padding bits in the high positions. Recipients MUST NOT interpret bits outside of the least significant bit. Senders MAY set bits outside of the least significant bit to any value without any impact on meaning. This allows future use of other bits as flag bits.

I understand the intent: only the least significant bit determines the boolean value, leaving the remaining bits available for potential future use as flags.

However, this design seems inconsistent with how flags are handled elsewhere in the protocol.

For example, in messages that explicitly use flags, such as SetupConnection, the spec uses a U32, with each bit clearly defined as a flag:

sv2-spec/03-Protocol-Overview.md

Line 250 in aadcb32

| flags | U32 | Flags indicating optional protocol features the client supports. Each protocol from protocol field as its own values/flags. |

From a user perspective, this is much clearer. Using a BOOL both as a boolean and as a potential future flag container adds cognitive overhead without an obvious benefit.

A simpler and more consistent approach would be one of the following:

• Treat BOOL strictly as a boolean (0 = false, non-zero = true), or
• If flags are needed (now or in the future), use an integer type and explicitly define it as flags.

The current BOOL approach also introduces unintuitive edge cases. For example:

• 2 (0b00000010) → false
• 3 (0b00000011) → true
• 4 (0b00000100) → false

While this behavior is correct per the specification, it is surprising for a type named BOOL.

I looked for historical context in the repository, but the earliest reference I found was during the migration from Google Docs:
#1

If there is a stronger rationale behind this design choice, I may be missing it. As it stands, the current design appears to favor hypothetical future flexibility over clarity and consistency.