MicrosoftSorry but I do not see the reason for such a function; it offers a solution to a problem I do not have.
The only times I have used entire column references is when I was testing code performance against 1048575 rows (plus a 1 row header cell) or where it is immediately intersected with a row-wise range. I normally use Tables to ensure all my named ranges correspond to source data and grow with it.
To use the new functions I would have to find a way of defining the oversize container ranges before I have anything to trim, increasing rather than decreasing the effort needed. I also prefer to avoid concise code that relies excessively upon the use of 'special' punctuation symbols (both regex and number formatting have issues, but they are worth the effort). Nowadays I would have trouble even to spot the difference between ":." and ".:."
Somewhat contrarily, I do have a use for an operator that will expand a cell reference to the current region for source data. I can pick up dynamic arrays from the grid using "output#" but "source#" could expand the cell ref down and to the right until blank cells are encountered.
I will look out for examples where users do gain benefit from the availability of TRIMRANGE and will reassess when I get access to the function.
