As it turns out, certain control characters do in fact cause issues. I think the reason it worked yesterday was because the string was parsed incorrectly in the ESP8266 and it was causing some unknowns. I did test the following:

AT+CWSAP="test\x0a\x0d\x2c\x22","",1,0

AT+CWSAP="test

And they both work, so this leads me to believe this is the case (yes even though that second string is improperly formatted).

What I do know is that this device only supports SSIDs of 31 octets and the following control chars are invalid:

LF - 0x0a
CR - 0x0d
" - 0x22
+ - 0x2b

The first option is to reprogram the firmware, but I reckon that is a bit drastic and definitely not a portable option if the same issue happens on another Wi-Fi module.

Instead, let's mask out these invalid characters. We can create a bit mask for the octets that can be affected (we can ignore the tag and country code). Also I have decided to always just use 31 octets of the SSID to increase portability. This leaves us needing to free up some bits since we need 24 and only have 15 reserved. When I first set the SSID encoding layout, I favoured ease of decoding over saving bits (hence why everything was neatly obtainable in 32bit chunks).

I have now significantly restructured the SSID coding schema:

Edit: Added path loss coefficient selection (4 values).

I've kept the reserve bits in there as they will come in handy and opted to reduce other aspects of the schema instead. One extra feature bit factored for is 3D location mapping to determine your position in a room with nodes on the floor and ceiling (ideally in each corner of a cubed room). This ignores the height of floor requirements and uses all nodes available instead. This can be used in conjunction with alternate mapping enable (offset mapping). Developers might like to set an application ID for this so the client can ignore nodes that aren't located in the room. You could also use some of the reserve bits to specify floor numbers as well (or replace the country code with floor number). While you should use the same channel to get decent positioning information, I will experiment to see what values work best.

In the code, whenever the encoder encounters a control digit it doesn't like, it increments the value by 1 and stores true in the bit mask. The decoder then decrements the corresponding octet by 1 if it is set in the mask, before decoding.

While each access point may require a different coding scheme for it (different control characters might affect different models), provided two invalid control characters aren't situated together (their hex value) for that access point, all clients will always be able to decode the string from any access point correctly, without modification to the decoder. If we run into something that does, we still have reserve bits to play with (could create different adding schemes, e.g. add 1, or 2). I did contemplate just adding 32 to any control bit, but sometimes normal characters are affected (like the + character in this instance).

So here it is working: