Inconsistent overload behaviour in TradingView's Pine Script v5

Question

I have had a problem and I seem to have found a bug in Tradingview's pine script v5 regarding the overloading functionality.
Code sample:

//@version=5
indicator("Overload recognition from within custom functions not working consistently")

mult(array<float> x1, string x2) =>
    [x1, x2]

mult(array<string> x1, string x2) =>
    array.push(x1, x2)
    x1

mult(bool x1, string x2) =>
    [x1, x2]

myFn(y1) => // workaround: must define parameter type for the overload to work successfully
    mult(y1, "Overload NOT recognized (unless used previously or type is defined explicitly before function parameter")

var stringArray = array.new_string(0,na)
// mult(stringArray, "Overload working as expected")
// mult(true, "Overload working as expected")
myFn(stringArray)
plot(1, "Overload recognition from within custom functions not working consistently")

The above code will throw an error by compilation:

 Add to Chart operation failed, reason: line 16: Cannot call 'mult' with argument 'x1'='y1'. An argument of 'string[]' type was used but a 'float[]' is expected

The problem is that if I use the y1 reference to the string array created before and invoke the mult(y1, "...") function from within myFn(y1) , the compiler cannot identify the reference type of my parameter and recognize the corresponsing function overload, responding with the very first match "you probably wanted float[], which is by the way wrong" .
There seems to be a reference error and by that an annoying bug in pine script.

Possible workarounds so far:

1. if I provide a type definition to my function myFn(array<string> y1) => , which I actually DO NOT want to, the correct overload is found
2. if I uncomment the following line: mult(stringArray, "Overload working as expected") before my function invocation, triggering some internal logic regarding the overloads with my corresponsing overload, the overload will be found later in my fn invocation too - actually not even a workaround... rather just a fact

Why the encapsulation so important is in my case? I am working on libraries.
Does anyone have a better idea for now?

Answer 1

As of today ( 2022-08-08 ), the bug was confirmed by the TradingView Pine Team and a task was opened to fix it. Hopefully, we'll get a TV update soon solving the issue.
Further research : no other workaround so far other than the one suggested in the question. No array manipulation helps with the type reference.