In a Public Transport context, the local_ref will typically be something like “Platform 1” or “Bay A” or "Stand A”. While that satisfies the “isn’t unique across the whole network” phrasing, it isn’t the full story.
As a result, GTFS platform_code from stops.txt is typically reconciled against OSM local_ref.
Various organisations in Oz use the platform_code in stops.txt, others don’t. If we want consistency for data consumers across Australia, we are going to have to consider that “local_ref” has reserved usage (for PT entities), and is not open for a free-for-all…
Yes I agree, local_ref is being used in that way, so it’s a fair argument to say it shouldn’t also be used for tram stops where each stop along the route has a number, e.g. stop 1, stop 2, etc that are only unique to the route, not the whole network.
The gtfs feed for the Melbourne tram routes contains neither platform_code nor stop_code fields in the stops.txt file (unlike the feeds supplied for the other modes of transportation in Victoria), so there is nothing to map to the local_ref field.
Downstream data consumers are going to use the local_ref if it is present (as it provides disambiguation to the name), typically by appending it to the name with a space separator. In the case of Melbourne Trams, the name of the stop is effectively the primary key, so no such approach is required, and it is probably best to leave local_ref unpopulated. In the case of Melbourne buses, the local_ref (stops.txt platform_code) is, in fact, required for disambiguation and should be populated.