3. Each unit doesn't occupy the entire `building=` or `building:part=` . They shouldn't be added to the entire area.

Please don't apply `building=` to land-only areas

1. Please don't add duplicate `amenity=police` . There should only be 1 for each police station. This is Tagging For Renderer, Application, or Editor.
2. Please don't change `building:part=` to `building=`

Please don't add duplicate `amenity=police`

The problem is they are basically only handling `operator=` now, not `owner=` . So the acceptance is uncertain. OSM is usually quite cautious and suspicious towards `owner=` .
Some people can argue HKHA is the direct `operator=` , with HD behind that should be interpreted from `*:wikidata=` etc if needed. It may also be argued the managing company contracted is the `operator=` . So it's not immediately obvious and straightforward.

Please don't delete things you don't understand yet. They need to be reformed into `building:part=` properly.

That seems to be a misunderstanding. At least in this case, it will only be suggested when the `operator=` contains it. So it's only being formatted.
Ultimately, it's only a suggestion. You are responsible for accepting it. When there's already something better, it should be rejected.

Please don't change Housing Department to HKHA. That's the actual agent, more accurate, and has been used by some.

As mentioned before, please don't blindly add HA as `operator=` of HOS. They are no longer owners after being sold, nor usually the management.

Please don't Edit For Application. It's the responsibility of apps to handle controls, categories, and discoverability.

A related issue is how `name:zh-Hans=`, and `name:zh-Hant=` , etc is often added. That's the amount of permutation/combination on the extra work, for `name:yue-Hant=` etc. So the effect of all these needs to be considered.

Alternatively, we can add both `name:zh-Latn-pinyin` and `name:cmn-Latn-pinyin` , so that it is clear this is a software limitation. Hopefully this will discourage people from adding `name:yue=` .

You can say the names in Cantonese and Mandarin is the same. Unfortunately, this will simply encourage people to add `name:yue=` .

`name:zh=` could be interpreted as Cantonese in the form of Standard Written Chinese as well. Fundamentally `zh` would easier to be understood as Written Chinese. Language as spoken, which is what romanization is concerned with, would be better posed with using the more precise encompassed language.

And don't forget, there is `operator:zh=` , `brand:zh=` , `addr:*:zh=` is etc. That's the amount of work that has to be dealt with here.

How is the comparison the same? `name:zh=` is perfect in Taiwan, as Mandarin is dominant. But Cantonese is what's used in HK.
`name:zh=` is practically interpreted as Mandarin, as seen in iD. This causes more work in HK when people keep adding `name:yue=`, and even not adding `name:zh=` at first. The easiest solution is to interpret `name:zh=` as Cantonese in HK.
`zh` is a macrolanguage. The situation in HK calls more "precise" differentiation, which is "valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course." .
As `name=` is the most common name, `name:zh-Latn=` is best be equivalent to `name:yue-Latn=` . This doesn't fit `name:zh-Latn-pinyin=` .
If people see `name:zh-Latn-pinyin` , this will reinforce the image that `name:zh=` means Mandarin. The use of `name:yue=` will be encouraged, and this risks more `name:zh=` not being added.

If you suggest "If Cantonese being included in `zh` in OSM here, then its arguably this creates problems for, at least, Wikimedia sites using OSM." , then it seems you need to discuss a proposal with HK and Macau to redefine `name:zh=` to mean Mandarin, and start using `name:yue=` by standard. However, redefinition of such standard usually doesn't work.

That is, `name:cmn-Latn` and `name:cmn-Latn-pinyin` to be used. Otherwise, you cause an awkward situation where there is `name:zh-Latn=` and `name:yue-Latn` .
The international standards can also be read critically. Viz `jyutping` has `Prefix: yue` , but `zh-Latn-pinyin` is used instead of `zh--pinyin` for some reason. This doesn't serves the aim of consistency.

It seems you are basically asking everything in HK to be retagged to `name:yue=` ?
That was partly my personal opinion. What I'm saying is `name:cmn=` should be used in HK.

Please read the rest
"

o Each encompassed language's subtag SHOULD be used as the primary
language subtag. For example, a document in Mandarin Chinese
would be tagged "cmn" (the subtag for Mandarin Chinese) in
preference to "zh" (Chinese).

o If compatibility is desired or needed, the encompassed subtag MAY
be used as an extended language subtag. For example, a document
in Mandarin Chinese could be tagged "zh-cmn" instead of either
"cmn" or "zh".
"
"

As noted above, applications can choose to use the macrolanguage
subtag to form the tag instead of using the more specific encompassed
language subtag. For example, an application with large quantities
of data already using tags with the 'zh' (Chinese) subtag might
continue to use this more general subtag even for new data, even
though the content could be more precisely tagged with 'cmn'
(Mandarin), 'yue' (Cantonese), 'wuu' (Wu), and so on. Similarly, an
application already using tags that start with the 'ar' (Arabic)
subtag might continue to use this more general subtag even for new
data, which could be more precisely tagged with 'arb' (Standard
Arabic).
"