My instinct would be to use dired to assemble the list of files and then use the dired open file action, do the simple edit, save and close the buffer, which will return to the dired buffer again and go to the next file name all within an interactive macro. And then repeatedly execute the macro as it steps through each file.

Alternatively, manually assemble the list of files in a text buffer and use M-x ffap to open the file under the cursor, and do the same as above.

If this is something you will be doing frequently, then writing elisp may make sense, but you can get the elisp that a macro represents as well.

Start with an interactive macro.

(Not intending to make this a critique of all things TRAMP but I prefer to discuss in public with specifics rather than personal generalizations so that future readers can put comments in proper context.)

TRAMP has limitations on both functionality and performance due to it not relying upon any Emacs-specific technology on the remote system. However, the configuration of both Emacs and the networking services have a dramatic impact on the usefulness of TRAMP services.

I have found that, with properly provisioned remote access and servers, TRAMP, while not instantaneous, is responsive, and can simplify complex file manipulation and editing without specialized configuration anywhere but the local Emacs instance. With TRAMP and Eshell, I am able to copy a file from an on-prem docker instance directly to an AWS EKS instance with a single cp command including file path completion. It might be sluggish completing file names initially, once the cache warms up, the interaction is usable. Obviously, copying 30MB between systems is not something you want to do frequently but if you do, Emacs and TRAMP are not the preferred solution.

As an old greybeard, TRAMP over SSH is far better than editing and copying files over 1200 baud dial-up lines. If you don’t know what those are, don’t ask, you do not want to know.

Sounds like he could benefit from TRAMP…

What OS, keyboard layout, and Emacs version?

The lispy/emacs-like solution is to open each file, search it, and close it. Don’t optimize too early. Build the simplest most straightforward implementation and then worry about performance. But understand why the most emacs-like solution fails.

For reference https://github.com/typst/typst

Looking quickly at the spec, I don’t think much of the typst functionality would be used by an org exporter.

If you are interested in such an exporter, I’d recommend you put together a description of the mappings that you’d like to see. That is, what org features do you need and how does that translate into a typst feature; I’m not asking for an implementation, just guidance on the scope of a first-pass at the exporter. That will give someone with the technical skills to implement an org exporter guidance as to what features to focus on.