Current docs show list of arguments as a table:

It is implemented using 3 columns, which is not ideal as it leaves very little space horizontally, while suffering with a large empty space due to description is most of the time multiple lines height.

The new API docs, uses lists, with indent, and a lot of similar coloring in various places that makes it extremely hard to identify actual arguments that can be provided into constructor:

Especially for nested properties when passing more complex objects:

Table with a two rows would make it much better:

The new API docs has nice block with properties, methods, etc.

But the sorting order is from left to right, and with large gaps between items it is hard to read.
So the alternative is to use vertical sorting, but it requires a bit of trickery in CSS, specifically to know exact height of an element in order to guarantee number of columns.

Horizontal sorting:

Vertical sorting:

To implement vertical sorting, element should have the right height based on number of elements (in this example 32 elements, 3 columns, 28px height of an element) and generic CSS.
Height formula: height = ceil(count / 3) * 28px (308px).

<div class='list' style='height:308px'>
    ...
</div>

.list {
    display: grid;
    column-gap: 1rem;
    grid-auto-flow: column;
    grid-template-rows: repeat(auto-fill, [col-start] 28px [col-end]);
}

Search is an important tool for docs, and it is a powerful exploration tool.

New API docs provide very nice searching capabilities, but the order of results is not optimal:

In most cases class should be the first.

When the eyes are searching through content, it is best to reduce repetition or information duplication.
Currently all properties, methods, etc are duplicated in docs:

It also suffers in some places from non-distinct separation.

Remove duplication and provide more accent to meaningful information:

It would be great to have a very consistent color and style for links within docs. Color coding of different things - is great, but without consistency it is harder to get quickly familiar with things.

Code syntax highlight should match the color schema of the docs or vice-versa.

Use color only for meaningful color coding, and reserve a distinct color per type of element we want to highlight. E.g. Class should use the color that others don't use. And class should be everywhere highlighted with such color (lists, links, code examples, syntax highlight, etc).

Links

If anything is clickable, it should look as clickable, and other elements should not use same way of highlighting to avoid confusion.
Obvious navigation lists, e.g. list of properties, accessors, methods - do not require underlines.

Subtle underline can help with that:

Currently:

With underline:

Classes

For example, all classes are colored cyan:

But clickable links are all different colors:

Functions

Functions are purple:

But in docs it shows methods as Pink:

And then goes back to purple below for these methods:

But in syntax highlight we switch to yellow:

Properties and Accessors

In engine they are very close, in some rare cases it is worth to know distinction, but generally engine uses them interchangeably, without providing any meaningful difference to the user. End of the day accessors do behave like properties.
Biggest thing, is that list of properties and accessors - is a public API, and the splits into two separate blocks does not provide meaning, but makes it harder to overview.
Also they don't need to look different as they behave by the end user the same.
Obvious examples would be: Entity.path and Entity.name. But even everything else. It is confusing distinction in general for API overview:

The header on mobile isn't displaying correctly