The two pulses have two completely different reasons. Let me explain them independently.
The first one is caused due to a hardware race condition on the module due to the fact that you are holding down the nRESET_EXT (pin 26) during power up. There is a circuit which debounces the nRESET_EXT signal. Unfortunately, the debouncing circuit is sometimes not fast enough to pull down the internal reset line before the PMIC actually releases the reset. The debouncing delay is actually depending on temperature and component tolerances. Therefore, the pulse does not appear on all modules and all conditions. Interestingly, you are the first one who noticed this pulse. I am not aware of other reports. We have been also not aware of this pulse, since we did not test it with the reset button hold down during power up.
The solution would be to reduce the debouncing time. I have created an internal ticket for changing it in the next revision of the module. However, since the Colibri iMX6 is in the production phase, we will only change product version if it is absolutely necessary. This reset pulse at the beginning is not going to cause issues on the module and it is very unlikely that it will cause issues on cusomer carrier boards. Therefore, the priority for this change is low.
The second pulse is created intentionally in order to resolve an issue we had with the hardware version 1.0. The PF0100 PMIC on the module is not capable of generating a reset output pulse if the software is requesting a reset. More information including a workaround can be found in this article: https://developer.toradex.com/knowledge-base/colibri-imx6-nreset-out-software-reset-workaround. With the Version 1.1 of the Colibri iMX6 module, we included the workaround on the module. There is basically the same circuit on the module. However, there is one little difference. In order to make sure that older BSPs are still running on hardware V1.1, there is a pull down instead of a pull up on the driving GPIO. This means, the reset is directly released, even if the software does not drive the GPIO. This also means, the reset is released before the bootloader has booted. As soon as the bootloader takes control over the GPIOs, it is driving the external reset low again and releases it.
We did not get reports of any issue with this second reset pulse. However, if it creates problems with your hardware, you could remove the second reset cycle from the u-boot. The drawback is that software initiated reset will no longer generate a reset pulse on the external reset.