You raise many interesting problems. While I have answered each one individually below, the general answer is: Typst is still a young project and while its already possible to create papers and other documents in it, lots of stuff is still missing. In the long term, we definitely want to handle all sorts of complex layout requirements, but for now we're working to get the basics right. That being said, here the individual answers:

> 1) Is it possible to create new structure elements and rules how they can be nested? Now there are headers of several levels, and it's all?

At the moment you cannot define custom structural elements, but you can define a function that produces some layout and the result is very similar. The structural aspect becomes more important when different parties need to agree on the meaning of something, i.e. you and Typst's standard library or you and a package author, so that the styling system also works with for those elements. We will add support for defining custom structural elements down the road.

> 2) What's about tables? 2.a) Multipage tables? 2.b) Multipage tables which have alternative orientation - like landscape table in portrait book?

Tables exist, also multipage tables. The table sizing is already quite flexible (and inspired by CSS grid), otherwise the customization is still quite primitive, though. We will improve tables in the future, for sure. See also here: https://typst.app/docs/reference/basics/table/

> 3) What's about inserts, which must be placed in exact break in the main text?

Do you just mean a block between two paragraphs? If so, that's possible, yes.

> 4) What's about marginalia? Marginalia which must be synchronized with text?

Not implemented at the moment, but planned.

> 5) What's about multicolumn layout? 5.a) What about multicolumn layout which is interrupted by single floating object (which belongs to page, not one column) - there could be two styles, when columns above and under floating object are independent and when they are continue after interruption.

Typst does support multicolumn layout. Floating objects that interrupt both columns are not possible at the moment, but we're aware of the requirement.

> 6) What's about multiple flows of text, synchronized? Think about bi- and triple-lingual texts, like translations of legal documents or poetry. Different flows could go to different pages (odd-even) or different columns on one page, but each page/column must contain same text, even if one language is more compact than another and one page/column will be systematically underfilled.

This is obviously a bit more complicated. I can see supporting something like this, but only in the long term.

> 7) What's about poetry, and modern poetry especially, where each line can require its own indentation (look up Mayakovsky's poetry).

You can create manual line breaks and insert horizontal spacing. Do you imagine a more automatic way?

> 8) What's about footnotes? 8.a) Long, multi-page footnotes? 8.b) Nested footnotes, more than 2 levels of them? 8.c) Nested multi-page footnotes?

This is one of the basic things that is still missing, unfortunately. But it has relatively high priority and we want to ship them before the public beta launch in March.

> 9) Is it possible to create "Problem / Solution" object typical for textbooks? I want to type problems and solutions together and automatically place all problems where they are typed, but move all solutions in designated place (like, last chapter)?

This will be possible with Typst's introspection system (which is already implemented, but not yet fully exposed to the user).

> 10) Is it possible to have Initials automatically?

Not yet, but planned.

> 11) What's with custom alignment rules? For example, in some typographic traditions last line of aligned paragraph must be not shorter than 1/3 of paragraph's width, and must be aligned too if it is longer than 2/3.

Exposing more control over paragraph layout is something I've wanted to do, but we haven't designed such a system yet.

> 12) What's with layout engine in general? Is it TeX' box-and-glue model? Is orphan/widow control customizable?

It's not boxes and glue, but we use TeX's optimal paragraph layout algorithm. Orphan/widow handling is currently baked-in, but similarly to exposing more control over paragraph layout, we also want to expose more control over flow (i.e. page or subbox) layout in the future.

> 13) What's about non-rectangular images? 13.a) Alpha channel support for runaround? 13.b) Additional vector path for runaround? 13.c) Choice should image be trimmed or become background?

Not prioritized, but planned.

> 14) What's about layouts typical for magazines, like "Cosmopolitan"? It is weakest point of TeX-like DTP systems :-(

This is a hard problem. We want to support content flowing across multiple boxes, which is of course a requirement for such a layout. But overall, I think the hardest part is not making it possible, but making the creation of a magazine in a markup-based system actually hassle-free. When creating a magazine, you just benefit much more from dragging stuff around with the mouse than if you're writing a research paper.