Do you know the meaning of this unique Id, 5e-4d-3c-2b-1a-99-88-77?

That does not seem like any unique ID at all. It is a set of numbers that follow a systematic pattern. If you reverse those bytes, the pattern is:

77,88,99,1A,2B,3C,4D,5E

A unique ID or MAC address would typically be totally different. For example, many Silicon Labs devices have address that is in the form 00:0B:57:xx:xx:xx (the first part is Silicon Labs organizational identifier and the latter 3 bytes are basically random (but unique).

What firmware are you running on the MG13? Is it running some BLE sample app or something else? And what tool did you use to capture the data (the screenshot in your first post) ?

I think it should work like this:

you use the UART DFU version of Gecko bootloader on your BGM123. The bootloader is able to handle the DFU independentely after the device is booted into DFU mode. In that sense, it does not matter if the main application is working in NCP or soc mode.

One special thing you need in a soc mode application is some way to trigger the DFU boot. Your soc application must call cmd_system_reset(1) to put the device into UART DFU mode. This could be handled using for example some GPIO line. 

Alternatively, Gecko bootloader has an option to use GPIO to enter DFU mode. If you use this option, then the bootloader will check the state of the GPIO pin at boot and if the pin is at given state, the bootloader will wait for DFU instead of jumping into main application. With this solution, you would enter the bootloader mode by setting a GPIO pin to the given state (can be configured hi or lo) and then reset the BGM123. This of course requires that your UART DFU host has control over the reset pin of the BGM123.

See the security subtopic in the KB article list -> 

https://www.silabs.com/community/wireless/bluetooth/knowledge-base.entry.html/2018/04/08/kba_master_list-MxiO

This same topic was discussed in another thread and I posted a working code example there, have a look at:

https://www.silabs.com/community/wireless/bluetooth/forum.topic.html/not_able_to_changethenameofthedeviceandstor-VwOU

I wrote a working example that shows how to save device name permanently on PS. See attached file.

This is based on the soc-empty example (from SDK 2.12.3). All my changes are in app.c.  Additionally, I ticked the variable length checkbox for the device name characteristic in the GATT editor and then pressed Generate to re-generate the GATT source files. (By default, the name is fixed length 13 bytes "Empty example")

There are two functions that handle the name saving / loading. They are:

vLoadDeviceName() : called at boot event to load the saved name from PS (if it exists)

vSaveDeviceName(): this is called whenever a remote client writes to the device name characteristic.

I tested this on my kit and seems to work fine.

There's something fishy about the ps_load_object function. First of all, when you call it you pass the length of devicename string as parameter. However, that parameter is not used for anything.

Also the implementation of ps_load_object seems completely wrong. You read a value from PS, but then your memcpy copies the content of devicename to the caller (devicename is copied to pvalue). That makes no sense at all? The data that is returned from PS by call to gecko_cmd_flash_ps_load() is completely ignored.

Here's how I would try to fix it:

static uint16_t ps_load_object(uint16_t key,void *pvalue, uint8_t size)
{
    struct gecko_msg_flash_ps_load_rsp_t *resp;
    resp =gecko_cmd_flash_ps_load(key);
    if(resp->result == 0)
    {
        // original version:
        //memcpy(pvalue,devicename,strlen(devicename));

        // fixed version:
        memcpy(pvalue, resp->value.data, resp->value.len);
    }
    return resp->result;
}

There's something fishy about the ps_load_object function. First of all, when you call it you pass the length of devicename string as parameter. However, that parameter is not used for anything.

Also the implementation of ps_load_object seems completely wrong. You read a value from PS, but the your memcpy copies the content of devicename to the caller (devicename is copied to pvalue). That makes no sense at all? The data that is returned from PS by call to gecko_cmd_flash_ps_load() is completely ignored.

Here's how I would try to fix it:

static uint16_t ps_load_object(uint16_t key,void *pvalue, uint8_t size)
{
    struct gecko_msg_flash_ps_load_rsp_t *resp;
    resp =gecko_cmd_flash_ps_load(key);
    if(resp->result == 0)
    {
        // original version:
        //memcpy(pvalue,devicename,strlen(devicename));

        // fixed version:
        memcpy(pvalue, resp->value.data, resp->value.len);
    }
    return resp->result;
}

Alternatively, if you're not afraid to do some small tweaks to your TBS2 board then you could try this:

Just remove the resistor R107 that is connecting USB 5V to the USB cable detection. This would mean that the board still gets power from USB, but the USB cable detection is cheated to think that there is no USB cable connected. 

Any tweaks are obviously at your own risk, but I don't see too much risk of making any permanent damage here 

Here's a snippet from the TBS2 schematics:

There is USB cable detect logic that will drive USB_PGOOD signal, which will wake up the "debug MCU". If you just need to power the kit from USB but you don't need any J-link, VCOM etc then it may be possible to get around this: if you power the board via the "5V" pin (as noted in the schematic, see above) then the USB cable detect logic is bypassed. I think this should mean that the debug MCU stays off (or in deep sleep).

If you cut the USB cable (the micro-B connector side) and use the GND / VBUS wires to power the TBS2 (via breakout pins 1 and 18) then I believe the debug MCU should stay off, resulting in smaller current consumption.

Check out this KB article on VCOM settings:

KBA_BT_1208: Using virtual COM port (VCOM)

 I suggest you try to adjust the VCOM settings, i.e. the parameters that are stored on the TBS2 board. There is a MCU on the TBS2 that implements the virtual COM port and you can adjust the flow control, baud rate etc settings via Simplicity Studio (as explained in the article).

You should also make sure that in the TBS2 project that you are working with the USART is configured to use HW flow control (RTS, CTS).

I don't think the settings you change in Putty have any impact on the VCOM operation. The data between PC and TBS2 is exchanged over USB and that should be reliable. If data is dropped, I believe it is between the TBS2 on-board MCU (the one that implements VCOM) and the Wireless Gecko chip that your TBS2 application runs on.