remarks fixed.

I love this. Over to @jilles for the final say (and of course if anyone else has anything to say).

Владлен,

• Reword sentence about non-POSIX extensions (chose second variant suggested by ziaee).
• Change missed occurrences of 'Non-standard' -> 'Non-POSIX'.

Hmm...

The sh utility is the standard command interpreter for the system.  The
current version of sh is close to the IEEE Std 1003.1 (“POSIX.1”)
specification for the shell. Non-POSIX extensions are marked below.
This man page is not intended to be a tutorial nor a complete
specification of the shell.

The sh utility is the standard command interpreter for the system. It's
behavior is standardized in the IEEE Std 1003.1 ("POSIX.1") specification
for the shell. Any extensions which are non-POSIX are marked below.
This manual is not intended to be a tutorial nor a complete specification
of the shell.

This is hard because I really feel that information on standards belongs in the standardized section for standards, called STANDARDS... The first sentence is sacred, it's been there since the beginning and cannot be improved upon.

Change 'nonstandard' -> 'non-POSIX'.

I absolutely love the base premise of what you're trying to do here. This will be a major accessibility win for the faction which supports promoting portable programming, which FreeBSD is one of the main champions of.

looks good, thank you!

Мелкие корректировки непринципиального и рекомендательного характера.

Grammar improvements:

• Prefer American English: 'non-standard' -> 'nonstandard', 'behaviour' -> 'behavior'.
• 'a nonstandard local command' -> 'the nonstandard local command'.

Let's not mention the behaviour when return exits the shell during an EXIT trap action, since it's obscure and probably incorrect (I think it's supposed to work like exit, with a difference between return by itself and return "$?", but in practice it always ignores the argument during an EXIT trap action).

There's more we can do elsewhere, but this one logical change is complete and increases consistency.

In D55169#1262390, @kib wrote:

In D55169#1262376, @tembun_bk.ru wrote:

Thank you! Do you think that kld(4) would be an appropriate place for this description? I guess I can incorporate it there.

Current kld(4) page needs a complete rewrite. Starting from the removal of LKM references, which were not relevant since 4.x.
The renovation for kld(4) is technically complicated work, requiring a lot of code reading to provide good manual.

In D55169#1262376, @tembun_bk.ru wrote:

Thank you! Do you think that kld(4) would be an appropriate place for this description? I guess I can incorporate it there.

In D55169#1262234, @kib wrote:

In D55169#1262072, @tembun_bk.ru wrote:

In D55169#1262058, @emaste wrote:

How about just load kernel module?

That's fine with me. However @kib already suggested to provide more information on what the 'kld file' is: https://reviews.freebsd.org/D55170#1261544. I thought maybe we can put this information in kld(4) for instance and use it as reference in kld*(2) man pages?

No, technically we load 'kld file', which is linked into the executing kernel. The file might contain some number of modules (from 0 to arbitrary), which are used as units of initialization.

In D55169#1262072, @tembun_bk.ru wrote:

In D55169#1262058, @emaste wrote:

How about just load kernel module?

That's fine with me. However @kib already suggested to provide more information on what the 'kld file' is: https://reviews.freebsd.org/D55170#1261544. I thought maybe we can put this information in kld(4) for instance and use it as reference in kld*(2) man pages?

In D55169#1262058, @emaste wrote:

How about just load kernel module?

How about just load kernel module?

Correct wording.