Martin, the odd thing with the SCO protocol is it's expecting an bluetooth address as a byte string (ex b'12:23:34:45:56:67' [note the `b`]) where the other 3 are expecting a regular string (ex '12:23:34:45:56:67').  I think it may have been a case of someone doing a blanket search-and-replace and missing the consequences there, but I'm really not sure.  However, this is somewhat besides the point as right now I'm trying to focus on just documenting the actual behaviour.  ;)

The issue is, what versions have the changes from 23ab586c427a in it, and what versions come before that where it's probably expecting a regular string.  Unfortunately I can't access the web interface for the repo at the moment so I can't even try to figure that out at right now.  (Though, I haven't confirmed that the old method was looking at regular strings or not...)