Resolved Joomla Menu Associations fail when multilingual menu items share the same path in one menutype

Hi Roland,
I found a reproducible issue with Joomla Menu Associations import in RO CSVI.
Environment

• Joomla 6.1.3
  
• RO CSVI 9.12.0
  
• PHP 8.4.8
  
• One frontend menu: mainmenu
  
• Languages: en-GB, zh-CN, de-DE, ja-JP
  
• Joomla Language Filter enabled
  

The multilingual menu uses one common menutype for all languages.
Equivalent menu items intentionally use the same logical alias/path in each language.
For example:

en-GB   Industries       path: industries   menutype: mainmenu

zh-CN   行业应用          path: industries   menutype: mainmenu

de-DE   Branchen         path: industries   menutype: mainmenu

ja-JP   業界別ソリューション   path: industries   menutype: mainmenu

Joomla itself accepts this structure correctly because the menu items are assigned to different languages.
Issue 1: Association target lookup does not distinguish language
I first created the Industries Menu Association manually in Joomla.
I then exported the menu item with RO CSVI.
RO CSVI exported the associations field as:

zh-CN#industries#mainmenu|de-DE#industries#mainmenu|ja-JP#industries#mainmenu

I therefore used the same format when importing the association.
The import completes without a visible error, but the expected Menu Associations are not created correctly.
In the RO CSVI debug log, the association targets are looked up using queries such as:

SELECT id

FROM #__menu

WHERE path = 'industries'

AND menutype = 'mainmenu'

The lookup is repeated for the different target languages, but the SQL does not include the menu item's language.
In this case there are four menu items with:

path = industries

menutype = mainmenu

but with different languages:

en-GB

zh-CN

de-DE

ja-JP

So path + menutype is not sufficient to uniquely identify the association target.
I would expect the target lookup to also use the language from the associations value.
For example:

SELECT id

FROM #__menu

WHERE path = 'industries'

AND menutype = 'mainmenu'

AND language = 'zh-CN'

and correspondingly:

language = 'de-DE'

language = 'ja-JP'

Workaround test
To verify whether the problem was specifically caused by the non-unique path, I temporarily changed the three non-English target aliases so that their paths became unique.

zh-CN   industries-assoc-zh

de-DE   industries-assoc-de

ja-JP   industries-assoc-ja

I then imported:

zh-CN#industries-assoc-zh#mainmenu|de-DE#industries-assoc-de#mainmenu|ja-JP#industries-assoc-ja#mainmenu

With unique target paths, the Menu Association was created successfully.
After the association was successfully created, I changed the three aliases back to:

industries

The Joomla Menu Association remained intact after restoring the original aliases/paths.
This appears to confirm that the association mechanism itself works, but the target lookup becomes ambiguous when multilingual menu items share the same:

path + menutype

Expected result
RO CSVI should use the language specified in the associations value when resolving the target menu item.
For example:

zh-CN#industries#mainmenu

should resolve the menu item using:

path = industries

menutype = mainmenu

language = zh-CN

Actual result
The lookup appears to use only:

path = industries

menutype = mainmenu

which is ambiguous on a multilingual Joomla site where equivalent menu items use the same path.
Issue 2: Updating associations changes the menu ordering
There is also a second issue when updating an existing menu item.
The test import uses:

Keep Menu ID = Yes

and updates an existing English Industries menu item.
However, the debug log shows the existing menu item being saved with values including:

parent_id = 1

level = 1

lft = 0

After the import, the Industries menu item moves to the first position in the menu.
I also tested adding:

menuordering = 3

to the import file.
The result was the same: Industries was still moved to the first position.
So an import intended only to add/update associations also changes the existing Joomla menu tree ordering.
Expected result
When updating only the associations field of an existing menu item, its existing menu-tree position should remain unchanged unless ordering or parent-related fields are explicitly being changed.
Actual result
The existing item is repositioned in the Joomla menu tree during the association import.
Suggested improvements
Could you please check whether the Joomla Menu Associations import can be improved in the following areas?

1. Use language together with path and menutype when looking up association target menu items.
   
2. Avoid changing the existing menu tree position when only associations are being updated.
   
3. When Keep Menu ID is enabled, preserve the existing menu item's ordering and nested-set position unless those fields are explicitly being imported.
   

This is particularly relevant for multilingual Joomla websites that use one common menutype for all languages.
Joomla itself supports this structure, including equivalent menu items in different languages using the same logical alias/path.
Version comparison
I originally reproduced the issue with:

RO CSVI 9.8.0

I then upgraded to:

RO CSVI 9.12.0

and repeated the same test.
The behavior is still reproducible in RO CSVI 9.12.0.
I have the RO CSVI debug logs and the one-row test CSV files available and can attach them if needed.
Thank you for looking into this.