This is a great project. And I have a couple suggestions.
1) Decoding the j-bits for PC control is the most interesting part of this project. The j-bits have a specific pattern which helps in their efficient decoding - this is clearly part of a well thought out design. Given the book's objectives I believe it would be a good idea to point this out; that is, that a carefully designed instruction can facilitate an economic hardware implementation. Without giving away the pleasure of the project's design, an additional sentence could be added in the next to last paragraph in section 5.3.1 to point this out.
Suggested sentence: As part of a well-designed instruction the j-bits have a specific pattern to facilitate hardware implementation.
2) I found the text in figure 5.8 misleading. The text implies that the ccccc..ccc instruction bits can be connected directly to the A register, Mux16, etc. Quoting: "...we don't specify which bits go where..." This misleading is further emphasized in the schematic which shows the ccccc....cc instruction coming in and the A register, Mux16, etc having c connections. When in reality these c-bits are not directly connected.
Suggestion: simply label these A register, Mux16, etc connections with some other letter.
Just my thoughts. Your suggestions are not unreasonable, but I don't know to what degree they align with the authors' goals. There are numerous places where they could expound on the beauty and simplicity of their design, but they appear to have refrained from that in general. I think the reason is that the project is so vast in scope that they have to keep it laser focused on just what needs to happen for this project -- notice that the set of basic chips doesn't even include a 2-input NOR gate because it turns out it just isn't needed for the project. So I suspect they would be reticent to add that just in the interest of keeping the material is lean as possible.
On the c-bit notation, I think the intent there is to have 'c' mean nothing more than a generic control signal, not that there is a one-to-one mapping between a bit in the instruction and a particular control signal in the design. But I agree that, at first blush, it seems like that might be what is being said (especially since, for many of them, that's what it turns out to be). Perhaps better would be to use to different letters or even to explicitly enumerate the control signals in the design with a subscript. That would not only suggest an obvious naming convention for signals in the implementation, but would also make it much easier to refer to the various signals in the text.
I would recommend that they add a part, say InstructionDecode, at the top level that takes in the instruction word and the flag bits from the ALU and produces each of the control signals. I think that would be a better match to the level of abstraction at that level of the design compared to having a bunch of glue-logic parts sitting there.