TYPO3 Core

Short answer: No.

Long answer:

The reference operator is not a true language construct. It is tokenized, but the copy operation itself is not handled in TypoScript parsing.

It is only done for single specific paths on the fly in the Frontend (it can't be used in pageTS config at all) when needed, in ContentObjectRenderer->mergeTSRef().

The reason is the reference operator can only be resolved after the full tree has been calculated (since the reference operator "understands" changes to the referenced tree part even after a reference has been declared).

To fully resolve this, TypoScript would need a full traversal after everything else has been done to copy the final tree into the target at the very end. This is do-able, and I actually tried that when I rewrote the parser in v12 - If you are really curious, you'll find some patch set that contains an according visitor in the main v12 TS parser rewrite WIP patch, I could look that up if you really need this.

This had one "not cool effect", and one "blocker": First it's not cool to traverse the entire TS at the end, but the kicker is: This makes TS explode in size - easily factor 20 or more. The cache files aren't small already, and tens of megabytes is simply unacceptable. And there is runtime memory as well. I realized at this point why Kasper back then implemented `=<` for cObjGetSingle() only: The tree would be far too big without the feature, and he needed some solution for the relatively big single content type TS definition to have something that does not eat too much memory. That's why it's there and for cObj only. The deal Kasper did was like this: "Ok, I'll resolve =< on the fly for particular situations. There may be 30 different content elements, but a single page rendering only uses like 3 or 4 different ones. So I'll resolve these 3 or 4 on the fly when needed, but not all of them." This deal is still true with `=<` and when I tried to dissolve the situation, I failed hard.

From my point of view, there is currently no way to change this systematically since my tests trying to make `=<` a full language construct simply did not work out. The only possible improvement in current handling that I see is caching the result of the reference resolve operation in memory and prevent doing it multiple times when there is more than one same content element on a page (like two or more TEXT elements). This may improve performance a little bit since the reference operator resolve operation could be suppressed for consecutive calls of same type of elements. I didn't dig hard into this in v12 since that requires a bigger rewrite of ContentObjectRenderer since cObjGetSingle() never knows the full path to a TS snipped, but only receives the "local" data part, making it impossible to have unique identifiers that are required for any cache solution.

I hope this answer satisfies you. I currently see no way to make this a full language construct and will close the issue. Note I of course discussed the situation with other core team members, this was not a I/me decision ... just in case the above text reads like that. If you think we're wrong in this area, you're of course invited to have a look at the situation to see if you can find an acceptable solution that we didn't.

@Christian Kuhn Thanks for your explanation.

And how about a new operator?

&foo = SOMETHING
&foo {
  bar = baz
}
bar =< &foo
bar {
  x = y
}

Where foo is an explicit reference and gets stored in a separate references-hashtable?