My concern with introducing new partial route relations is the following...
1) Why is there a need to maintain multiple relations just because the line is not yet open/under construction?
2) Who will maintain these routes relations and merge them once the line opens? Isn't it simplier to just update the role instead of having to edit the existing route relation and delete the 'temporarily' relation?
3) Is there any uses that cannot be satisfied by using the documented role=stop nodes already in the relation, and ignoring the unknown/new role=stop_inactive nodes? There is nothing odd about having planned/under construction parts of the line in the route.

Also note that OSM neither restrict users from inventing new tags, nor state that route relation shall be made-up of active-members only.

If this change is to simply satisfy the PT route validators, I am sorry to inform you validators are a low-priority and PTv2 is not a good proposal anyway due to the un-necessary complexity. I would priortise having the most accurate routes (both in-use and planned/under construction), and most importantly have the route easily maintained in the event of changes in the route due to new station opening.
osm.wiki/Proposed_features/Refined_Public_Transport

Hi,
Please try to use a different relation role instead of entirely removing the relation node from the route relations.

Hi,
Please try to use a different relation role instead of entirely removing the relation node from the route relations.

It will be better to correctly classify it as route=apm instead of route=monorail.

Hi,
Monorail may be classified as APM, but not the other way round.

Something is wrong with this changeset, as NSE is not ready yet and thus no way that the highway left construction phase.

In terms of relation, it will be preferable to just use another role (i.e. construction_stop) instead of role (stop) for the member node instead of deleting the node from the relation. By deleting off the node, it makes maintenance of such relations difficult.

The node itself is already tagged with the construction tag so no issues with that.

Hi,
I don't think there is a need to remove the stop node even if the station is still under construction, because the node stop itself is already marked as under construction.

Hi,
Can you stop spamming parks where it doesn't exist? If it is not defined as a park anywhere else, it is not a park and at most a grass patch.

Hi,
Can you stop spamming parks where it doesn't exist? If it is not defined as a park anywhere else, it is not a park and at most a grass patch.

Hi,
Can you stop spamming parks where it doesn't exist? If it is not defined as a park anywhere else, it is not a park and at most a grass patch.

Hi,
Can you stop spamming parks where it doesn't exist? If it is not defined as a park anywhere else, it is not a park and at most a grass patch.

Hi,
Can you double check if the postal code is correct? It appears that the previous postal code seems to be in order.

Hi,

For consistency you may want to tag the building with addr:neighbourhood instead of name instead.

Hi,
The station entrance should not be mapped as the train station building, as the train station consists of all the linking tunnels and concourses.

I would suggest ignoring the building in building validation. The validation doesn't really work well for building complexes with multiple addresses.

More importantly, places with addresses should be correctly tagged and searchable, else the POI information will not be useful.

Hi,
This changeset corrupted the 3D building parts for the building:part at...
way/440538817

In addition, changing the from building to building:part also lead to the building address not being searchable in Nominatim.

Hi,
You may refer to the following building outline.
way/46671404

Hi,
Your addition of building heights for Harbourfront building ignores the building parts (and the various building levels) that already exists for that building, and will overlap with the 3D building parts.

May I suggest that you double check on this?

Thanks.

This changeset introduces lots of incorrect access=no tags on nodes of a way.

Suspect user highlighted all nodes and ways and applied access=no to both nodes and ways, instead of applying it to ways only.