Laurenz

> A place scope is missing, but that is better left to another PR. This first needs more consideration and design as well since there is not even a page...

In light of https://github.com/typst/typst/pull/6387, there was some discussion on Discord about this. Various people were in favor, but @Myriad-Dreamin brought up that supporting this from an IDE perspective could cause...

Personally, I think we need to unpack what exactly "dynamic" means for an import. There's actually two related, but different kinds of dynamicity: Dynamic _import expressions_ (which already exist), and...

> Doing this with custom types would give opaque return values which is not great for a data-loading package... Could you elaborate on this point? I'm not sure I understand.

The plan is that type identity (for show & set rules) is determined by source code location + hash of all captured values. This is in line with what Zig...

I think having types instanced multiple times at all will be rather rare. I didn't have any plans for detecting incorrect show rules thus far.

The docs for `query` could be updated to use this. There might be more places.

I'm on board with the `display(at: ..)` parameter, but for now I'd rather not add it to `get` and deprecate `.at()`. It's not off the table, but I'm not confident...

Maybe we should move the improvements to matching numbering handling to a separate PR so that this one purely adds the new `at` API?

Oh, that's why the other PR is draft and contains the commit, too! I thought you'd do it the other way around since the matching does not depend on `display.at`,...