You may see that the trace() (that always returns 1) is eliminated from the expression, thus making this kind of use impossible. I may use line() to overcome it, but doing this is less convenient (takes more restructuring) than this technique.

So I ask Andrey, if possible, please disable optimizing out the trace() call. (Yes, I understand that passing a complex expression as an argument to F() may result in side effects, but this is up to user who wants to trace things.)

I think this is not related to vectorize(); trace() is evaluated on function definition and since can handle symbolic data -> does his job on the output window and returns 1 (that is the value stored in the function - vectorize acts on what it knows, and what it knows is what is stored -> x^2). Solutions: use trace(eval(x))) or use a programming function F(x):line(...)

Wrote

I think this is not related to vectorize();

I also don't think so; vectorize() was used only to make multiple calls to the function to demonstrate that the output doesn't contain the multiple traces.

Quote

trace() is evaluated on function definition and since can handle symbolic data -> does his job on the output window and returns 1 (that is the value stored in the function - vectorize acts on what it knows, and what it knows is what is stored -> x^2). Solutions: use trace(eval(x))) or use a programming function F(x):line(...)

Thank you. Well, I know the solutions (I cited one of them above); I included the tooltip to demonstrate the elimination in the resulting internal representation of the function; I only asked for a new possibility - to avoid the exclusion of trace() while processing the function definition on the grounds that SMath knows that its result is always 1. trace() is a debug function; it's not wise to eliminate debugging facilities (it's not C++, where I may use conditionals to control inclusion of debugging facilities).

Wrote

Thank you. Well, I know the solutions (I cited one of them above); I included the tooltip to demonstrate the elimination in the resulting internal representation of the function; I only asked for a new possibility - to avoid the exclusion of trace() while processing the function definition on the grounds that SMath knows that its result is always 1.

Ah! I beg you pardon, read it again and you are right

Maybe we may think to avoid any preprocessing on none optimization

By the way: it would be awesome, if trace() woudn't return 1, but instead returned its argument itself (unchanged, unlike eval()). This way, we could simplify everything.
Consider this:

F(x;y):=x*y

I want to trace x. So instead of what I have to do now:

F(x;y):=trace(eval(x))*x*y

I would do simply

F(x;y):=trace(x)*y

This way, the very problem of trace() elimination could be solved, because its return would not be constant, but depend on its (last?) argument.
And by the way: eval() in trace won't work nicely in case of vectorize(), because it will trace the vector value of argument, not the individual params (thus, for instance, will be unhelpful if I want to find which specific input gives error and stops execution).