PuTTY's default behavior when receiving the null char '\0'

Question

I am looking into some unexpected behavior on a terminal output regarding receiving a null char '\0'. I am sending a string which I am expecting will contain 2 \0, but this is not displayed on PuTTY.

According to this question it is implied that PuTTY does not send null under normal circumstances. However that question is approaching 10 years old and I would assume that PuTTY has received updates during that period.

I have looked into the PuTTY user manual and have mainly found documentation on PuTTY's panels and a lot on error messages and connectivity. Chapter 3.3 discusses "Altering your character set configuration" but is mainly involved with non-latin alphabets, and it links to Chapter 4.10, which is the translation panel.

My question is simply, what does PuTTY normally do when it needs to receive a \0 char over? Does it not receive it? Does it receive the char but is not displayed in the terminal?

Please let me know if more information is required.

Code used for sending data to PuTTY is in C, on an STM32 board:

static int8_t CDC_Receive_FS(uint8_t* Buf, uint32_t *Len)
{
  /* USER CODE BEGIN 6 */
  USBD_CDC_SetRxBuffer(&hUsbDeviceFS, &Buf[0]);
  USBD_CDC_ReceivePacket(&hUsbDeviceFS);

  memset (buffer, '\0', 64);  // clear the buffer
  uint8_t len = (uint8_t)*Len;  //Converts Len as uint32_t to len as uint8_t
  memcpy(buffer, Buf, len);  // copy the data to the buffer
  memset(Buf, '\0', len);   // clear the Buf also
  //Code used to send message back

  /*In the full version, there will be another function outside of this file.
   * The buffer will be processed and a proper message will be sent.
   * Check that other file to see how it gets processed when we eventually implement it.
   */

  uint8_t transmit_message[64] = "TOWST_FIRMV_REEEEEEE_27\r\n"; //Do we have \r\n?
  //CDC_Transmit_FS(transmit_message, sizeof(transmit_message));
  //HAL_GPIO_TogglePin(GPIOF, GPIO_PIN_10);
  //message_Received(buffer, len);
  process_Message(buffer, len);
  return (USBD_OK);
  /* USER CODE END 6 */
}

void process_Message(uint8_t* message, uint16_t Len){
    HAL_GPIO_TogglePin(GPIOF, GPIO_PIN_10);
    uint8_t* inputCmd[5];
    uint8_t* inputMessage[8];
    uint8_t outputCmd[5];
    uint8_t outputData[8];

//  strcpy((char*) inputCmd, (const char*)message + COMMAND_CHAR);
//  strcpy((char*) inputMessage, (const char*)message + DATA_CHAR);
    if (strcmp(inputCmd, "FIRMV") == 0){
        memcpy(outputCmd, "FIRMV", COMMAND_LENGTH);
        memcpy(outputData, "01050A00", DATA_LENGTH);
    }
    else{
        memcpy(outputCmd, "REEEE", COMMAND_LENGTH);
        memcpy(outputData, "99999999", DATA_LENGTH);
    }

//  message_Received(message, Len);
    send_Message(outputCmd, outputData);
}

void send_Message(uint8_t* cmd, uint8_t* data){
    uint8_t outputMessage[25] = "TOWST_";  //Size of array is for future uses.
    strncpy((char*) outputMessage + 8, "FIRMV", 5);
    CDC_Transmit_FS(outputMessage, sizeof(outputMessage));
}

    //Expected output: 'TOWST_\0\0FIRMV' based on this post, which per my understanding suggests that strncpy will fill in unfilled memory with null chars. https://aticleworld.com/how-to-use-strncpy-and-how-to-write-your-own-strncpy