Hi @cefitzger thanks for your feedback.
I agree it might be confusing, but not all combinations of security params are valid, e.g. some of them are mutually exclusive. If you set "lesc" to true, then all other parameters get ignored. I've tried to describe this in the documentation here: https://www.espruino.com/Reference#l_NRF_setServices
Note: Not all combinations of security configuration values are valid, the valid combinations are: encrypted, encrypted + mitm, lesc, signed, signed + mitm.
Effectively all your tests were done using "lesc". Not all BT devices support this security protocol, I think it has been introduced in BT 4.2 specification. I assume one of your android device, ios or pixl itself does not support it, hence fails establishing security channel.
I did some test using a sniffer (nrf51822 and android 7.x), what I saw is similar to your WireShark trace, but after a successful pairing response I saw that all data packages were encrypted, I could not even see what type of packages get exchanged, e.g. the software I used could not decode radio packages.
Re rationale of having security configs per each characteristic. I agree this might be confusing, but if you consider characteristics as abstract resources, then why would not you have different levels per each? I can make up an example. Let's say you have a peripheral device that can report some data which is not secure (open). You may connect to it and read that data, you may chose not to establish or not to establish secure channel (pair or not pair), this is a valid case. But also that device provides a characteristic that is used to change some settings, this one has to be secured hence you mark it as secured, i.e. forcing central to establish secure connection just for this characteristic. I think it makes perfect sense having different levels per each characteristics (and not globally).