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.