When registering a base UUID with the SoftDevice via "sd_ble_uuid_vs_add", a uint8_t is returned which (per the ble_app_pwr_profiling example) is intended to be the "type" field in a "ble_uuid_t" variable. The SDK documentation indicates (S132 SoftDevice -> API Reference -> BLE SoftDevice Common -> Events, type definitions, and API calls -> Functions -> sd_ble_uuid_vs_add) that this "type" is actually an index into a table of base UUIDs. Index #0 is "Invalid" or "UNKNOWN". Index #1 is "Bluetooth SIG UUID (16-bit)". Index #2 is the start of vendor-specific base UUIDs, "Vendor UUID types start at this index (128-bit)". I'm a bit confused by these comments. In reality, ALL the base UUIDs are 128-bits, and once installed, ALL the relevant API calls deal with 16-bit UUIDs that replace bytes 12 and 13 in the base UUID. Is that right?
So the SoftDevice would then have TWO UUID systems, one rooted at the Bluetooth standard base UUID which is "built in" the SoftDevice, and the second at the randomized vendor-specific base UUID installed via "sd_ble_uuid_vs_add". Thus, standard GATT services and custom GATT services can operate simultaneously, and the Bluetooth stack in the SoftDevice takes care of the advertising and the communication of service contents without further attention from the software developer. Therefore, once the service is initialized and the characteristics added, there is no need to keep track of the index in the ble_uuid_t variable returned from "sd_ble_uuid_vs_add". Is that right?