This is not superfluous, and you give an example modified recently for another purpose in France by another editor; These names are not so easy to derive from relations, in fact what is given is the fact it is an international boundary (at admin level 2) and the two countries are named consistantly (there's no need to give names for higher levels: Länder/régions, départements, arrondissements/(Land)kreise, municipalities... because they are obviously part of the lower level).
Names for relations and names for ways serve different purposes. Renderers may want to display the local name of a way or the global name of a relation, this depends on how maps (or custom reports) are made and their intent.

There's no general rule to derive local names from multiple global names set in a parent relation, you cannot infer that easily and the same is true for other inference in the reverse direction from local to more global (espacially for countries where there are many exceptions with shared or disputed areas and different "official legal" sources with different level of precision (and lack of official conflation between their definitions).

As well, relations for countries are not exactly divisions: they overlap in some cases (for disputed areas). Identifying these overlaps is not evident (including the overlap between Luxembourg and Germany along the Moselle River, by a condominium, but German districts including parts of the condominium !)

Final note: we absolutelty need the names for rivers, espacially those on international borders, because their official name change or depend on the side (the same is true for street names). You cannot take the names from their parent waterway or street relations: the relation name is not rendered locally on map but used only when searching a full river or street by one of its local names.

International boundaries require specific tagging to limit damages by unaware contributers that forget to manage relations on the other side, and ways international borders are used in many relations that are frequently broken and can be difficult to restore. The names make things more obvious for those that want to split/jpoin these ways (and are warned they could break the relations), and for those that will repair them without ambiguity. It takes time to search and identify what belongs to were and it is much longer to repair than to break these in a single click.

1. Rivers are named (Le Rhin, La Lauter, La Vielle Lauter, La Moselle) and dual named in tow languages when they are on the border. This is usual.

2. International borders are also named for visibility and clear distinction in the editor, even if these names are not rendered. This also helps mixing different tagging systems between countries and avoid confusion in editors. These names are not necessarily translated in many languages, jsut a few for interest of editors in local languages or reviewers.

Note: this changeset was more than 5 years ago ! It was needed at that time because there were mixes of boundaries by confusing borders for different countries (they first were broken creating a hole, and then the wronf borders were selected to "fix" the hole incorrectly, with that confusion!)... Another proof that these names are needed for editors even, if they are not rendered.

note: the SHOM 2019 is more precise that the previous import of EUROSION, which was very fuzzy, and incorrect (it used data in ED50, but this old import forgot to convert it to WGS84, and this data is outdated and had poor resolution and many approximations).
I use SHOM2019 data which defines nodes every ~250 meters with accuracy of points at ~1 meter; EUROSION used much broader precision with one node every ~7 km on average and an accuracy of about 100 meters, but the strokes were simplified too much in some corners; some strokes were also incorrectly computed, not using the correct baselines, others were just estimated, and EUROSION data does not reflect the actual laws and various international agreements that occured since the earlier estimation.

Anyway, there should be no ambiguity for the 4-letter script code using a capital initial, when it follows a 2-letter or 3-letter main language code and a dash. Looking into the database, both spelling have been used, but this does not change the meaning for BCP 47. Both are recognized. I've not seen a consistant use everywhere, I can apply the capital letter here if you want, this does not change the meaning and should not impact the use; yes it would be better to uniformize this, but some applications recognizes language tags only when they are in lowercase (because uppercase is used for something else, like country tags or other OSM suffixes added to the "name=*" tag (like ":left" or ":right" used for example for naming segments of streets or rivers forming a border of two distinct cities/regions/countries possibly using different languages or using completely unrelated names for streets).

the keys in lowercase are OK for the validator in JOSM. This is not true when using the capitalized first letter for the script code.
Note: language identifiers are NOT case sensitive in BCP 47, they have only a suggested lettercase, but OSM wiki documents that language codes should all be lowercase, leaving the uppercase letters for other uses (not for language tagging)

So I have to search manually in lot of objects in many changesets... There must be one way at least that appears (I searched with Whodidit, many changesets are not visible there, possibly a database problem not revealing them, with too many edits at that period or in an unprocessed large diff; I note that the databse has some lags)

There's been lot of modifs from various users here. with some deletions. Because I have splitted the closed way to merge the existing unclosed claimed boundaries, several were deleted. But I can't even see those that were deleted (because of duplication after merge) even by me. Has there been a redaction process that hides some edits?
Unfortunately I've not recorded the way id concerned.
Note also that the supposed claim from France is smaller and not reflected in the French cadastre; if you see the recent edits I made there to improve rthe boundary (that were roughtly estimated and visibly drawn by hand, It now matches the French cadastre for the French claim (southern most limit. I've still not redrawn the Italian clamed border (northern borders).
You can see the the French claim on Monte Blanco di Courmayer is the North-Eastern half of the glacier and not the whole.
Also the borders are not exactly the ridge but follow paths along and sometimles around the summits.
If you are not sure compare with the French cadastre (this does not limit to use the Italian Cadastro to place their own limit, but the French claim is correct.
Also using imagery here (even the best one aviable here: BDOrtho) still shows some parallax, so tracing the visible ridges would not be absolutely exact. The only accurate measures are made on the field with precise GPS and reported on cadastral documents. It's hard to get an imagery that reflects everything exactly, even if the border "should" (may be?) follow the natural ridge.
Note: I have no interest to the dispute even if I'm French, I think this area should be comanaged by the three surrounding countries, for the best protection of the area. And in all cases the three countries cooperate largely for this protection and security, and search/rescue operations. Only the buildings (refuges, meterorological stations, and other security equipements are owned by one country or another and they respect each other and inform each other when needed)

To be precise, what was before was not a "relation", but a closed way iwith these tags, that was drawn over existing boundaries and causing geometric problems that were left, possibly after your partial revert.
I checked the boundaries there because it created conflicts, but did not ask why ther was this polygon, which is still a true dispute.
I only cleaned up the geometry, this changed the closed polygon into a relation with the same tags.

why did you move nodes ?
This is not a restoration.
These moves do not match either the French or the Italian cadastre... The nodes were correctly positionned (don't use Bing photos, it is incorrecftly orthorectified).
The locations you put are now offseted to the west.

Also I had not changed the positions of nodes of any related claim. Like what you did just there (possibly to restore them from cadastral sources from both countries.

Note that I did NOT create it, it was already thre and causing conflicts and geometry errors locally for an unrelated edit.
I tried to solve it but it was already there, created by someone else in one of the related ways.
Look at the history correctly (I've deduplicated some ways, the way where it was done by "Alecs" is still there !)

This was made by changeset/50859732

So I've not invented anything. Complain to the other user that created it first.

I kept it by removing duplicated overstroke ways and moving them to a relation with the same tags (admin_level=2 and boundary=adminitrative, and its existing names and wiki links, that are unchanged).
May be now you want it to have other tags, but these are not the tags I chose myself. I can if you wzant change it to boundary=disputed if you don't like the admin*, and remove the admin_levels on the relation.

I have NOT created it, it was already there as a polygon (single closed way) where I merged its touching ways, and had *already* these tags.
Look at the history of ways correctly

it was *already* with admin_level 2 (as a single polygon redrawn over the existing boundaries... It was then still already like a "country", it already had a tag "disputed".

The admin_level to give to this is not clear, the condominium at level 6 is not even better and even more wrong because it is an mutual agreement between countries and not subject to the local regulations, and admin_levels between Luxembourg and Germany do not match (so it should also be at admin_level 2, certainly not 6 and not any level > 2).
It's a fact that these agreed or dicputed areas are delimtied by national borders, beyond which there's no dispute and a single national juridiction and regulation possible at more local levels.

The purpose of this edit was to change a polygon into a relation, so they qhare the same border ways, and allow easy addition or removal of these areas without creationg gaps, depending on intended use if someoneone doesn't want these overlaps that may be listed separately.

Note that if you want to list countries only, you just need to exclude those areas with disputed=yes; but the countries will still overlap in those areas.