An attempt at this was started in,
https://github.com/wikimedia/mediawiki-services-parsoid/commit/55da3090d0e7faa49e40a5bce0f68634fea5fc83

but was reverted because of T301948, T302007, and T301986
https://github.com/wikimedia/mediawiki-services-parsoid/commit/61f39cdee96985ec6ef99067bada1113011d1c8c

This is going to depend on T301080 because Parsoid currently collapses all the frames so only template arguments from the first level of the expansion are available. Extension tags nested a few templates deep wouldn't see the right arguments.

Your memory and history is much better than mine even though I wrote those patches originally!! :-)

One proposal is for all parsing to take place in the context of a "data object", which would include both explicit (typed) parameters as well as a "data object", possible associated via wikibase query or some such. Some notes:

• T348722 has a proposal by Tim Starling for attaching data to the <section>
  • T230658 proposes syntax for “section attributes”, potentially something similar could use used to set section data ala Tim’s proposal?
• SMW and {{#set}} are discussed in T122934#9196348

Goals:

• avoid “from point of definition” behavior for {{#set}}-type data declarations.
• Avoid exposing entire frame stack implicitly to templates; instead pass data explicitly so dependencies are manageable.

Thanks @Alex44019 and @cscott for raising this one. I remember discussing it with the team a while back, but the Parsoid extension API was considerably less fleshed out back then.

Another option is a better varargs mechanism, like T204366#10521777, so that arguments could be explicitly passed from the parent context into the child, instead of implicitly passed via a context object. The problem with a context object is that it makes dependency computation and independent fragment re-evaluation difficult -- we can't use selective update on a fragment without knowing all the inputs to that fragment, including potentially the entire frame stack attached to it.

At the moment Parsoid uses the preprocessor to flatten the entire transclusion, so Parsoid doesn't actually have access to anything except top-level frame arguments. Providing access to the frame is thus blocked on reimplementing/integrating the preprocessor with Parsoid.