And bools are definitely a byte only on "new" C standard versions (as in since C99), before that there was no boolean type and ints were often used. Thus, LongBool.
Looking at the C 2011 standard, it looks like "_Bool" is implementation defined ( https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf , pg. 57 of the PDF; the page labeled 39 section 6.2.5 paragraph 2): " An object declared as type _Bool is large enough to store the values 0 and 1."
I believe everybody uses a single byte for that -- a single byte can store the values 0 and 1 -- but it looks like they aren't required to.
I believe C++ specifies "bool" is one byte; it's definitely never larger than a "char".
As far as std::vector<bool>, the fact that each value is defined at taking up a single bit inside the std::vector<bool> doesn't really say anything about how large each bool would be outside of the std::vector<bool>. std::vector<bool> was arguably a case of the Committee being too clever ( https://isocpp.org/blog/2012/11/on-vectorbool ).
I was burned so so hard by vector<bool> and have sworn to never touch it again. I wasn’t aware of the specialization and wrote a ton of code around it. Eventually needed to take a pointer to an element or range of elements and only then discovered that it was special.
I don't think "addressable" implies byte addressable or addressable by a single machine word. IIUC a bool* could be implemented as a byte pointer and a bit offset. Of course this then causes a cascade of things that you probably don't want like intptr_t getting at least 3 bits longer and size_t and related types may need to grow as well. So baking it a byte is the most practical choice.
