What is the use case for this and why can't the existing title column be used? Also, why would this be added to the database only and not exposed to the UI?

This is necessary to refer to a group of fields from the code, if the title matters for example in Cyrillic, or Arabic))
I'm now working on all the necessary files for this set.
I just did not find a way to merge several files into 1 Pull

By analogy with the table #__ fields

I just did not find a way to merge several files into 1 Pull

Just edit the additional file in the branch of this PR (eg patch-7) and the PR will automatically include all edited files.

On a sidenote: If you need to have the title of a custom field translated, just create a language key for that title (in the language override manager) and put the KEY into the title field. It will be automatically translated to the active language. No need to create some special code.

The field 'title' does have the not-ascii value - and if you refer to it in code, for example a template, you do need to write not-ascii characters in the code. In the 'name' field, the value ascii is automatically generated - and it is already possible to work normally with it.

In the table "#__ fields" there is a field "name", why in the table "#__ fields_groups" it should not be? This is exactly the same as the "alias" field in the "#__content" table, which is useful.

I constantly have to work with non-English-language sites, and the lack of this fieldis a big problem.

In addition, if you make a multilingual site, for example with the help of com_falang, the 'title' field will be translated, and you will have problems accessing it.

The "name" column in the #__fields table is used as the name of the field in a form. It's absolutely not the same as the alias in com_content, that one is used as an part of an URL.
The fieldgroups are basically fieldsets and their name is built like "fields-ID" (using the ID as identifier).

I'm not sure why you want to refer to the name of the group in your code. Just use the ID of the fieldset if you need that.

In addition, if you make a multilingual site, for example using of com_falang, the 'title' field will be translated, and you will have problems accessing it.

As said, core already does translate the title if you put a translateable KEY into the field. No need for com_falang at all.

The "name" column in the #__fields table is used as the name of the field in a form.
The "name" field can be used in addition to forms, as well as in a variety of user applications (templates, modules, etc.).
The "id" field is inconvenient to use. It is assigned by the system and can not be changed by the user, and therefore, if you install your application on a site with a different combination of additional fields, then the "id" will be different, and you will have to make changes to the code of your application.

It's absolutely not the same as the alias in com_content, that one is used as an part of an URL.
In spite of this, these fields have a unique ACSII key that can be used in the code, without the risk of receiving unexpected effects.

As said, core already does translate the title if you put a translateable KEY into the field. No need for com_falang at all.
Especially - how can you use a field as a key that has different meanings for different languages?

In my sites I use com_fieldsattach as CCK, and I try to transfer to your extension the experience with it.
A couple of additional fields will allow much more flexible use of its in templates and third-party applications.

In spite of this, these fields have a unique ACSII key that can be used in the code, without the risk of receiving unexpected effects.

The alias can contain unicode characters depending on the global Joomla configruation. It's not restricted to ASCII.

Especially - how can you use a field as a key that has different meanings for different languages?

I don't understand. Maybe I have to explain better.
In the language override manager you create a new override:

In the fieldgroup you use this newly created custom language constant (eg CUSTOM_FIELDGROUP_EXAMPLE_TITLE) as the title.
In the article form, it will show like this:

In your PHP code, you can use the constant as the identifier. The translation happens right where it is rendered.