This is indeed a defect. We should avoid trying to overwrite existing indexes.

I wonder, though, what WordPress code uses MATCH() AGAINST() querying on the postmeta table. It isn't natural language text and probably will yield strange results. Are you using a particular plugin? (Notice that FULLTEXT indexes aren't exploited except by MATCH() AGAINST() queries. Core contains none of those. Only a couple of plugins known to this author do contain them, and none on wp_*whatever*meta tables.

You could work around this problem by doing this query instead of the one we use for high-performance keys. This changes the name of the FULLTEXT key.

ALTER TABLE `wp_postmeta` 
    ADD UNIQUE KEY meta_id (meta_id), 
    DROP PRIMARY KEY,
    ADD PRIMARY KEY (post_id, meta_key, meta_id),
    DROP KEY meta_key,
    ADD KEY meta_key (meta_key, meta_value(32), post_id, meta_id),
    DROP KEY meta_value,
    ADD KEY meta_value (meta_value(32), meta_id),
    ADD FULLTEXT KEY meta_value_ft (meta_value), 
    DROP KEY post_id

I am also wondering what added that fulltext index, if you have time idid the diagnostic upload, the id is this: PCXPu8HB

I did not choose the theme + framework ( which is divi) but i have a feeling that the FT index was created by them.

I have uploads from some other Divi sites and they don't have this index. Strange stuff.

I was searching for all plugins and sources where it could come from, but the search for 'FULLTEXT' did not deliver any useful results. Is there any other way to find what is using that index?
Asking the other way: is the name if the index of any matter?

Yes, the name of the index is what causes our plugin to function incorrectly. The workaround I showed above changes the name of the FULLTEXT index.

I have heard of situations where people created FULLTEXT indexes in the belief that they would automatically improve search performance. That doesn't work; exploiting those indexes requires using the MATCH() ... AGAINST() query syntax.

Changing the name of this plugin's index would be a really heavy lift both for testing and for the plugin's users.

Yes, the name of the index is what causes our plugin to function incorrectly. The workaround I showed above changes the name of the FULLTEXT index.

I have heard of situations where people created FULLTEXT indexes in the belief that they would automatically improve search performance. That doesn't work; exploiting those indexes requires using the MATCH() ... AGAINST() query syntax.

Changing the name of this plugin's index would be a really heavy lift both for testing and for the plugin's users.

My question aimed the installation, where i haven't find anything what would create that index, making it unnecessary to keep the index at that name, or even the fulltext index itself.

I would say, the corrective steps would (depending on the mysql version pre 5.7, or 5.7 and past): recreate, or rename the index simultaneously presenting a warning about the action taken.

Question: do you need this issue to be open?