Let me reorg the discussion:
1. Every single building used for boarding purposes should be an `aeroway=terminal` + `buidling=*`, because `aeroway=terminal` on a `buidling=*` describes the property of usage instead of strictly indicating the whole terminal, which is the practice in OSM. All the examples raised by you (Except FPO) are notated as `aeroway=terminal` + `buidling=*`, even the remote gates hall in LAX (way/413226763) are notated as this.
2. From the examples you raised, I see the practice of using `type=multipolygon` + `aeroway=terminal` is quite common. Although I don't think it's a perfect solution, I accept this.
3. I insist that `aeroway=concourse` should not be used on `building=*` independently, it should only be used to describe the concourses under the same roof with other components. Further, there is no document or guide for this tag provided, so it is not understandable to any data parser.
4. HKIA official website map not only puts all T1, NSC, and MFC in one tab, but if you drag the map, you can find they also put SkyPier and 4 car parks in the same tab. The map clearly separates main T1 and MFC as 2 independent parts, as you can find that under T1 it writes "(Gate 1-80, 511-530)" while under T1MFC it writes "(Gate 201-230)", where T1 does not cover MFC. Interestingly, In this map T1 does cover NSC, which makes me believe it's okay to mark T1 and NSC as one building, but that is based on your suggestion of "if Sky Bridge is considered as a `building:part=bridge`". This is not "conflicting with my preferred definition", since main T1, Sky Bridge, and NSC have already been marked as a single continuous building.
5. I totally understand HKIA's current and future situation. HKIA is not the only airport using this structure. For example, LAX Midfield Satellite Concourse (way/831597425) is a satellite concourse only of TBIT; ORD T1 Concourse 3 (relation/13749364) is also a satellite concourse only of T1, they are mapped as separate terminal buildings, while there are also other terminals in the same airport. I believe it is good enough to follow the current practice.

Reply to Kovoschiz:
1. You mentioned the `aeroway=concourse` is "used by a few already", I found 9 in total - 2 nodes at RIC and 7 ways at FLL, and they are all inside a `aeroway=terminal` building, not used as a separate building. (For the word "invalid", You have used it in the first, I was just following you. But please don't dwell on this word choice further)

2. `aeroway=terminal` does not need to include the whole terminal system, it just describes the property of an element, that's like "this building is a terminal" instead of "the whole terminal is just this building". (If you want to have a single element for the whole T1, the jet bridges may also need to be included?) Taking HKU as an example, the Sassoon Road Campus is marked as `amenity=university`, which does not mean the campus is an independent university. You can say that's not perfect, but it is the practice in OSM - most satellite concourses, including the ones in ATL, are marked as separate `aeroway=terminal`s (ATL even using multiple `aeroway=terminal`s for one terminal). So, Marking MFC as a separate `aeroway=terminal` in OSM does not mean it is an independent terminal. Yes from the name we know that MFC and NFC are logically equivalent to the 5 concourses in main T1, but in reality, they are not, MFC and NSC are separate buildings but 5 concourses in main T1 are in the same building. Forcing the use of "consistent" tags will only make the data difficult to understand for the parser, for example, the Carto parser cannot understand the 3 buildings are terminal buildings and not rendered as expected shown in the wiki page. (This is not "tagging for render", it is a manifestation of data being misunderstood.)

3. A `type=site` + `aeroway=terminal` relation best fits your needs. A `type=site` relation is more like a management tool to show the logical relationship between different members in it. You can refer to the discussion https://help.openstreetmap.org/questions/60388/usage-of-typesite-relations for more detail. BTW, if you want to make main T1 and NSC to be one `building=*` with Sky Bridge marked as a `building:part=bridge`, I have no objection, but I still prefer to keep them separate since they are not built at the same time.

4. I agree. But since it is not a standard tag, I would express my objection to using `aeroway=concourse` on buildings independently (i.e. MFC and NSC), the reasons are as above. I think `aeroway=concourse` should only be used within an `aeroway=terminal` building.

5. I apologize for having not discussed this in your changeset first, because the changes made the data unusual so I fixed it at first. By saying ", and it seems to make no sense to me personally.", I mean your changes do not follow any diagram implemented by other airports (JFK does not implement the same diagram as yours) or any guide in wiki, and it made the data parsed unexpectedly, so it makes no sense to me. And I understand the purpose for adding the tags but it did not work as expected, and then replaced with documented tags on wiki. Last, I will "try to contact the author" next time.

6. Regarding your additions. I studied and found that in OSM and main-stream commercial map apps, satellite concourses are mostly mapped as separate terminals and I personally haven't heard anyone complain about this in real or on web. In the current practice, passengers can easily tell from the name which `aeroway=terminal` building is the main one - the main part is always marked as “Terminal X’ or “XX Terminal”, the same as their ticket shows, while the satellite concourses are marked with different names. A multipolygon terminal containing mant separate parts, on the contrary, will increase the understanding cost for passengers.

To sum up, for HKIA, I support to have a relation to put separate parts together logically, but not a split multipolygon, and each satellite concourse (MFC and NSC) should be an `aeroway=terminal` building. Further, I do not oppose to using `aeroway=concourse` for concourses inside an `aeroway=terminal` building. I wonder if a consensus can be reached.

Reply to Kovoschiz: First of all, thank you for the detailed comments. I attached my opinion as follows:
1. `aeroway=concourse` is invalid. The talk topic you provided is not discussed by anyone else, is not accepted, and is not used in JFK. Actually, according to overpass-turbo, this invalid tag is rarely used worldwide (only used in 2 airports)
2. According to [HKIA's official website map](https://www.hongkongairport.com/tc/map/) , T1, T1 MFC, T1 SC, SkyPier, and several car parks are marked as independent buildings with names in the same style. Of course, I can imply from the T1 prefix that MFC and SC are parts of the T1 system, but according to current practice, they could be treated as separate `aeroway=terminal` buildings like most satellite concourses in the world do, for example [LAS T1 - Concourse D](way/143887543). If they are different buildings, they can be separate `aeroway=terminal`s.
3. I understand and support that you are trying to relate these `aeroway=terminal`s to the T1 system, but there is no guide on wiki to create an `aeroway=terminal` but not `buidling=*` multipolygon consisting of multiple terminal buildings, and it seems to make no sense to me personally. To my knowledge, a Site relation is a good choice to describe the relations of several objects which together have a single identity according to [wiki](osm.wiki/Relation:site) , and most values of "site=" are not documented, so I create a non-standard one following the practice. But I realize that `aeroway=terminal` can be directly used on the Site relation, just like `amenity=university` site. Would that be a good choice to change the relation to `type=site` + `aeroway=terminal`? And should the car parks be included?
4. I agree that `building:part=` is not a good choice. `aeroway=concourse` maybe
a choice for the 5 concourses within the T1 main building, but it's not approved or documented. This issue could be explored.
5. Lastly, I was not trying to "remove tags that you don't understand". I fully understood the intention here (as described above) and the tags added, and I removed those tags based on my understanding. Please don't blame and keep calm to discuss.

Open for discussion.

感谢提醒，已修复

提醒阁下注意：您在本changeset中错误地删除了两条东莞境内的镇界路径，导致对应的镇界关系被破坏，此错误已由 Changeset# 147655223 修复，请您在之后的编辑中多加注意

注意到阁下近期在若干条深圳城市快速路出口添加的name标签，但这些name标签的value均为此出口的destination而并非name （详情请参见highway=motorway_junction#Name_and_number）
如若有异议可以在此讨论串提出，若阁下对该意见没有异议，本人将于7日后撤销这些name标签转入匝道的destination标签。

注意到阁下近期在深圳梧桐山片区添加了大量路径，包括道路和水路要素，首先感谢对OSM的贡献，但这些路径绝大多数没有确切来源，且大多数道路要素似乎出现在没有通行条件的区域，同时部分路径添加有无意义的name标签（如“x”、“溪”等），这在通常意义上被认为是不符合OSM规范的，鉴于阁下并未在变更集中种提供来源，若阁下有其他可验证的信息作为佐证欢迎阁下提供，也欢迎阁下对这些编辑做出适当的调整（删除没有可信来源或不符合Wiki描述的数据），若无法提供社区可能对阁下提供的编辑做出撤回

Reverted by [Changeset #140089218](changeset/140089218)
---
#REVIEWED_BAD #OSMCHA
Published using OSMCha: https://osmcha.org/changesets/139053082

Reverted by [Changeset #138730102](changeset/140088716)
---
#REVIEWED_BAD #OSMCHA
Published using OSMCha: https://osmcha.org/changesets/138730102

请问您批量添加的坝光地区地名是否来源？

Reverted.
---

Published using OSMCha: https://osmcha.org/changesets/135831833

Reverted.
---

Published using OSMCha: https://osmcha.org/changesets/135831833

"The names should be restricted to the name of the item in question only and should not include additional information not contained in the official name such as categories, types, descriptions, addresses, refs, or notes." —— osm.wiki/Names

okay, I guess I have understood the criteria here, but not quite make sense to public

I object to the opinion that motorway_link should be used in this Airport Road case. The main line of the road (i.e. Airport Road in this case) is not and should not be a link road by definition. The main line of motorway can be directly connected to a lower-level highway, a link road is not a prerequisite.

Labeling a highway=motorway together with motorway=no seems to make no sense, especially after Route 8 ended and transferred to another road with a different name. It is okay to label the linking bridge with the mileposts of Route 8, which is exactly what I have edited. But it should not be used on Airpoty Road an Tung Wing Road. The situation of the main road is different from the link road.

Please check Route 8 Expressway ended before the bridge connecting to Chek Lap Kok Island (with an expressway ending sign on the road), and Route 8 mileposts ended after the bridge. The [Airport Road], [Tung Wing Road] and [the bridge connecting North Lantau Highway and Airport Road] should not be highway=motorway!

①②③并不是站名的一部分，如果阁下乘坐过西部公汽运营线路车辆，应该会听到形如“深大北门1号站台”的报站语音，把站台号放在name里并不是以后结构化的数据，只是一种偷懒的数据形式。当然，渲染没有带上站台号也是偷懒。

回复 qq-aaa: 你好，根据阁下提供的信息及本人掌握之情况，可以认为当前此跨海隧道仍处于规划中状态而并未实际开始建设，因此应使用highway=proposed而非highway=construction，详情请见https://wiki.openstreetmap.org/wiki/Key:highway#Lifecycle_(see_also_lifecycle_prefixes) ，待工程开始建设之后再流转为建设中状态，本人将会执行此项编辑，请知悉。再次指出：已规划但未开工建设的道路请不要使用highway=construction，https://wiki.openstreetmap.org/wiki/Tag:而应使用highway=proposed 感谢配合！（因url错误重新发送）

回复 qq-aaa: 你好，根据阁下提供的信息及本人掌握之情况，可以认为当前此跨海隧道仍处于规划中状态而并未实际开始建设，因此应使用highway=proposed而非highway=construction，详情请见https://wiki.openstreetmap.org/wiki/Key:highway#Lifecycle_(see_also_lifecycle_prefixes)，待工程开始建设之后再流转为建设中状态，本人将会执行此项编辑，请知悉。再次指出：https://wiki.openstreetmap.org/wiki/Tag:已规划但未开工建设的道路请不要使用highway=construction，https://wiki.openstreetmap.org/wiki/Tag:而应使用highway=proposed 感谢配合！