Yes, I have already got it from source. And I also found that it resets and it can not run into my code. Really strange, and now I am trying to reset the micro via watchdag timer.

After some labs on board, it seems watchdog timer caused reset and NVIC_SystemReset() have same problems. After reset, it is clocked from resonator, so, everything goes slow.

Is there any method to manupilate clock source after reset? I have checked the source on github. I guesss it is related to system_stm32f1xx.c, how ever I have no idea how to debug that code, since it is already a library.

Should we report is as a bug?

I also did some tests on 103RB. Overall my conclusion is that with the mbed software, pulse width on NRST is critical. No matter from what source it comes from (pin, software or watchdog reset).

In tests with NVIC_SystemReset (), pulse width was of the order of 1.2ms. It was not enough.
I also tried to connect together pin NRST and free GPIO pin and using DigitalInOut class, I made a software reset by setting the pin as an output and setting its value to 0. The pulse width was about 0.27ms.
Too bad.

Returning to the test with NVIC_SystemReset (), I tried to extend the width of the reset on NRST attaching additional capacitor 10uF to existing 100nF.
And it worked!
After this reset, the system works as it should.

The pulse width, estimated at slightly more than 10ms, difficult to measure accurately because of the slope, and difficult to estimate the level of switching system in 103RB. Unfortunately, I find it hard to tell if this is a good solution. And what does tolerance to variable factors of the system.

But in general I agree with you that the reason is the clock initialization procedures.
I suspect that it refers to a file:

https://developer.mbed.org/users/mbed_official/code/mbed-src/file/4fa1328d9c60/targets/cmsis/TARGET_STM/TARGET_STM32F1/TARGET_NUCLEO_F103RB/system_stm32f1xx.c

or incorporated there HAL functions:

https://developer.mbed.org/users/mbed_official/code/mbed-src/file/4fa1328d9c60/targets/cmsis/TARGET_STM/TARGET_STM32F1/stm32f1xx_hal_rcc.c

A little strange to me, that just mode without quartz crystal or external clock (HSI), works well, although it is chosen at the end of the tests where other options are not working.

Problem solved!!!
I added a delay before the initialization function of the clock and the software reset (NVIC_SystemReset ()) works fine. And probably the watchdog reset will also work well.
Value of additional delay 4ms is bad, for 7ms the test program begins to operate properly but not every time, for 10ms It looks like it is ok, because I think the value of 30ms is safe.

Here the modified section of the file "targets / cmsis / TARGET_STM / TARGET_STM32F1 / TARGET_NUCLEO_F103RB / system_stm32f1xx.c", with changes in the function SystemInit:

  /* Configure the Cube driver */
  SystemCoreClock = 8000000; // At this stage the HSI is used as system clock
  HAL_Init();
  
  /* delay absolutely necessary when a narrow reset pulse on the NRST or/and with software or watchdog reset */
  HAL_Delay(30);
  
  /* Configure the System clock source, PLL Multiplier and Divider factors,
     AHB/APBx prescalers and Flash settings */
  SetSysClock();

This is not an answer (I'm sorry for that). When I tried to post a comment the web UI just gave a blank screen, so I just posted an answer which seems to have worked.