This breaks the multilingual editing associated items.
I am firmly opposed to this change

Opening in a new special window (not a modal) was specifically introduced to display a limited edit for the associated item to prevent possible errors and make it easier for the user.
We choose to not propose a real modal as we were getting issues when having to display a modal in a modal (Clicking on Article and Images button at bottom of editor pops a modal over the modal).

The page opened is a "fake-modal" with a specific design
/administrator/components/com_content/views/article/tmpl/modal.php
(we have similar pages for core components accepting multilingual associations)

Specificities:
Category and Language can't be edited.
Header and Toolbars are absent
Associations are NOT proposed
Specific buttons for "Save & Close" and "Cancel" close the new window and the browser focuses again on the original associated item present in its own window: Example

Original article (in French) for which we will edit the associated English article:

After clicking on the Edit button for English (UK):

Thanks for the explanation! Now I understand the idea of the new page.
Close this, because it was not a bug :-)

But, if possible, it would be good to use the code you propose ONLY in the case described here, i.e. when editing an article in the single article menu item.

I tested this:

diff --git a/administrator/components/com_content/models/fields/modal/article.php b/administrator/components/com_content/models/fields/modal/article.php
index 9d02df9..9c53e57 100644
--- a/administrator/components/com_content/models/fields/modal/article.php
+++ b/administrator/components/com_content/models/fields/modal/article.php
@@ -139,5 +139,14 @@
        if ($allowEdit)
        {
-           $html[] = '<a class="btn hasTooltip' . ($value ? '' : ' hidden') . '" href="index.php?option=com_content&layout=modal&tmpl=component&task=article.edit&id=' . $value . '" target="_blank" title="' . JHtml::tooltipText('COM_CONTENT_EDIT_ARTICLE') . '" ><span class="icon-edit"></span>' . JText::_('JACTION_EDIT') . '</a>';
+           if (isset($this->element['language']))
+           {
+               $html[] = '<a class="btn hasTooltip' . ($value ? '' : ' hidden') . '" href="index.php?option=com_content&layout=modal&tmpl=component&task=article.edit&id=' . $value . '" target="_blank" title="' . JHtml::tooltipText('COM_CONTENT_EDIT_ARTICLE') . '" ><span class="icon-edit"></span>' . JText::_('JACTION_EDIT') . '</a>';
+           }
+           else
+           {
+               $html[] = '<a class="btn hasTooltip' . ($value ? '' : ' hidden') . '" href="index.php?option=com_content&task=article.edit&id=' .
+               $value . '" target="_blank" title="' . JHtml::tooltipText('COM_CONTENT_EDIT_ARTICLE') . '"><span class="icon-edit"></span>' .
+               JText::_('JACTION_EDIT') . '</a>';
+           }
        }

It uses a new "normal" window to edit an article when EDIT is used from the Single article menu item, and the "special" page when we deal with associations.

What do you think?

I don't see the reason to limit the edit form when coming from association. You can change anything when you directly edit it from the article manager. Why not when you open it from the menu manager? Why should the behavior be different?

In the case of the menu manager, one can choose ANY article with any type of settings. This is fine. If the user chooses/modify an article and sets it to another language or another category, it may be a mistake but it will have no effect on the associations.
In the case of associations, I explained above the reasons why:
1. we do not let the user move by mistake through a full admin page to something else
2. we do not let the Category and the Language be changed as this would kill the already set association and possibly make a real mess...
3. We do not let setting another association that would also kill the settings.

1. we do not let the user move by mistake through a full admin page to something else
2. we do not let the Category and the Language be changed as this would kill the already set association and possibly make a real mess...
3. We do not let setting another association that would also kill the settings.

My point is, we allow to break those associations when we are coming from the article manager directly. You can change an associated articles language or category when you edit it regulary. You just can't do that when you come from the association tab of an article or from the menu item.
Imho, it should either be prevented always (maybe best option), or never. But it doesn't make much sense to only restrict it when coming from a certain point.

I tested here modifying through the normal article manager an article tagged to en-GB.
There was already an article associated to it tagged to fr-FR as well as other articles associated in other languages
I modified the language from en-GB and saved as fr-FR without touching at the associations.
It did not mess with the associations table, it just replaced the associated article tagged to fr-FR by the modified one and kept the associations with the other languages.
Evidently there were no more article associated to en-GB in that association group.
The non modified article tagged to fr-FR lost all its associations.

This is something we do not want to do when we edit an article from the associations tab.

I think there should be a warning/error when you change the language of an already associated item or formfield should be disabled with a tooltip explaining why it's disabled, regardless from where you come.
The current thing looks quite hackish to me.