If I understand correctly, the only way to save custom calculated values ​​for use in parameters is to calculate them in Wrangle and save them in a small layer, then read the pixel value where needed.
But this doesn't work for me, and I'm not sure if it's a bug or if I'm doing something wrong.

1) Create a constant with a test color different from 0 and 1, for example, purple.
2) Create an sdfshape and enter an expression for reading the first pixel into the radius. We should get the radius based on our pixel value, right?

The search shows several functions :
1) pic/picni. I enter picni("../constant1", 0, 0, D_CLUM) - and it returns 0. I tried the spare parameter, absolute paths, and all kinds of color types - everything is still zero.
2) volumeindex/volumesample - the result is also 0. The VEX volumeindex function works fine in Wrangle, but not in hscript.
Could someone in the know please tell me if I'm mistaken or if these functions don't work at all in Copernicus? Or is there another way to pass expressions from Wrangle to another node's parameter?

Largely, the answer here is no. If a parameter depends on pixel values and is set by an expression it means we can't keep the computation on the gpu, so have to bounce back to the cpu. Historically this results in networks that are impossible to then make gpu friendly, so we consciously did not make it easy to do this.

We're not happy with the current state as we want to drive these things ourselves, so are looking for ways to enable it properly in the future

But what can you do today?

pic expression is the old cops only, but I see our docs didn't say that. I've added a note to that effect.

volumesample must point to a sop, not a cop.

So the current complicated work around is to use a sop net in cops. Dive into that and put down a copnet sop and set it to fetch an external cop. Point to the cop you want to read. This gives you a volume. Now back at the original cop level you can write a volumesample expression that points to the copnet node inside the sopnet.

Note that this will be a break point in graph evaluation, we'll not be able to compile through this, so it won't work in blocks, and there may be performance issues as it bounces through the CPU. But if there is a will, there is a way...

Thanks for the clarification and solution, jlait!
Frankly, I (like most users) am not too concerned about graph breakpoints; a simple mechanism for parameter management is much more important.
I think we spend infinitely more time battling with complex options for simple calculations than a fast graph would save us, and it's not worth it. Time is precious.

I think it would be very productive if you implemented more user-friendly solutions for parametric parameter management in Copernicus.

For now, I'll use sop, as you suggested. In principle, I can simply store detail attributes there.

Yeah, detail attributes with a detail() expression is probably the easiest approach for now.