If you add the `building=yes` tag to the perimeter, you'll get a “building-within-a-building” warning and duplicate segments.

The solution used in this case seems to work, but it isn't applicable to all types of buildings.
It works because you used the key `tourism=hotel` on the area without specifying the area type (`building=hotel`).
You should check OSMOSE’s response, perhaps starting here: https://hdyc.neis-one.org/user/9_tab

On the site, in the 2D view,
the area covered by the hotel is the one bounded by its perimeter.
In the 3D view, the parts of the structure are displayed without taking the perimeter into account.
Another option is to use a site-type relationship, but this does not seem to be encouraged.

In that case, separate the buildings and repeat the same information for each one.
You can't combine them into a multipolygon relationship, which is used for areas.
The solution is the “building” relationship; you'll find a link above explaining how to use it correctly.
If you don't like that, separate the buildings and keep them separate.

No, the buildings haven't been removed; they've become parts of the building grouped together by the “building” relationship
relation/19970640.
These are the three parts:
way/179543605
way/179543544
way/179543673
Here is the 3D view:
https://demo.f4map.com/#lat=46.2107151&lon=6.1459138&zoom=21&camera.theta=40.989&camera.phi=7.162

If you verified during your site visit that the hotel is accessible from both streets, then the current map entry for the hotel is correct.

The initial multipolygon grouped the three parts of the building as parts of the hotel, so it follows that way/1560483661 is the perimeter of the hotel.
If this does not match reality, the perimeter data should be moved to the part corresponding to the hotel, leaving only “building:yes” on the perimeter.
I hope I’ve understood the question correctly and clarified the solution.

According to the timeline, the “relation/19970640” multipolygon was created and edited by you using changeset/176200527 to connect the three parts of the building.
As you can see https://tools.geofabrik.de/osmi/?view=areas&lon=6.14666&lat=46.20985&zoom=16&baselayer=Geofabrik%20Standard&opacity=0.71&overlays=duplicate_node% 2Csingle_node_in_way%2Cduplicate_segment%2Cway_in_multiple_rings%2Cintersection%2Cintersecting_segments%2Cring_not_closed%2Ctouching_rings%2Crole_should_be_inner%2Crole_should_be_outer%2Cinner_with_same_tags%2Cways% 2Cduplicate_node%2Csingle_node_in_way%2Cduplicate_segment%2Cway_in_multiple_rings%2Cintersection%2Cintersecting_segments%2Cring_not_closed%2Ctouching_rings%2Crole_should_be_inner%2Crole_should_be_outer%2Cinner_with_same_tags%2Cways
OSMI reports a violation of the multipolygon rules. For merging parts of a building, it is recommended to use a “building” relation
osm.wiki/Relation:building
I apologize, but OSMOSE is not involved in this case.

I should note that I did not enter the data myself.
I simply integrated the existing data to eliminate the reports in OSMOSE caused by non-compliance with the rules on multipolygons.
For the integration, I used Bing's 3D views.
https://www.bing.com/maps/search?style=3d&q=46.2105888%2C+6.1460936&cp=46.210538%7E6.145854&lvl=20.4&eh=435.89&dir=64.99&pi=34.96

I should note that I did not enter the data myself.
I simply integrated the existing data to eliminate the reports in OSMOSE caused by non-compliance with the rules on multipolygons.
For the integration, I used Bing's 3D views.
https://www.bing.com/maps/search?style=3d&q=46.2092018%2C+6.1498038&cp=46.209272%7E6.149940&lvl=19.9&eh=431.42

The building number is unique and has been entered. The main entrance does not have a number, but it provides access to the entrances listed.

That is the main entrance to the numbers listed.

See addr:=**
and addr:flats=*

The building numbers correspond to the parts of the building as you entered them.

OSMOSE suggests changing the name in French. If you think it's appropriate, change the spelling in English, but I don't think it's correct.

??? il gruppo di modifiche 182170450 non è mio.

Hello,
As you pointed out, the node was moved unintentionally.
Thank you for bringing this to our attention and for the correction.
Happy mapping.

Ok. Allora sul nodo andrebbe specificato Località Colombari.

Sono perplesso, questa affermazione è sicuramente valida quando si inserisce il nome della località.
In questo caso stiamo inserendo un indirizzo non una località, pertanto mi sembra corretto inserire l'abbreviazione Loc. come si scrive l'indirizzo postale.

OSMI segnalava un problema alla relazione relation/20385035 in quanto tutti i membri erano contrassegnati come "inner".
Aggiornando la relazione con JOSM sono state rimosse le etichette dalle way in quanto i dati già presenti nella relazione e contrassegnando le way come "outer".

Az OSMI hibát jelzett a relation/20385035 jelentésben, mivel az összes elem „inner” jelöléssel volt ellátva.
A jelentés JOSM-mal történő frissítése során eltávolítottuk a címkéket a way-ekről, mivel az adatok már szerepeltek a jelentésben, és a way-eket „outer” jelöléssel láttuk el.

Hai creato la relazione multipoligono relation/20385035 per unire le aree omogenee. Ovviamente le etichette compaiono nella relazione.
L'etichettatura "railway=platform_edge" va applicata su una Way aperta, non sulle aree.

Létrehoztad a „relation/20385035” többpoligon-kapcsolatot az azonos jellegű területek összekapcsolására. Természetesen a címkék megjelennek a kapcsolatban.
A „railway=platform_edge” címkét egy nyitott útvonalra kell alkalmazni, nem pedig a területekre.

Non ho cancellato nessun dato inserito.
Hai circoscritto l'area del postal code utilizzando un multipoligono senza chiuderlo corettamente.
Ho eliminato la segnalazione circoscrivendo l'area estendendo uno dei segmenti del multipoligono taggandolo come boundary postal code, segmento che in seguito hai cancellato invece di estenderlo a coprire l'attuale area.
Con la tua eliminazione è andata persa la cronologia delle modifiche al segmento.
Ho eliminato il multipoligono perchè costituito da un unico segmento chiuso, quindi non necessario.