I'm guessing this has to do with encoding. According to this answer, an SSID may (now) have an explicit UTF-8 or UNSPECIFIED encoding, but the "SSIDEncoding" field is part of a newer standard. Presumably then on networks with equipment older than this, it is effectively "unspecified".
I would like to think that anything which sets an SSID from text input by humans would do it in ASCII or UTF-8. However, the standard specifying the SSIDEncoding field appears to be dated 2012, so previous to that, any encoding at all could be used (and any encoding at all could still be used, as UNSPECIFIED). So there could be some software somewhere that sets them in something else -- e.g., using ASCII but falling back on UTF-16 when a string contains odd characters. Java and I believe Windows both use UTF-16 internally.
The router almost certainly regards the SSID as a sequence of bytes and does not care about any potential encoding at all, so it will accept whatever it was passed when the SSID is set. To determine this, you'd have to look at the actual byte sequence as broadcast.
both systems can see the network, if it's not hidden.
It's possible to recognize a UTF-16 string for what it is, so when not hidden, that may happen and the SSID translated into local encoding for display. But when you try to enter it manually, the system can't know what encoding to use in the broadcast; it will only work if it matches the methodology of the software that set it in the first place. The new SSIDEncoding field does potentially resolve this, but A) it also allows for the UNSPECIFIED loophole, and B) older equipment won't care. Since linux and android generally use UTF-8, if the SSID is actually a UTF-16 string, it may end up looking the same on the screen, but not match up when entered manually and searched for.