Your only reasonable argument is that MAYBE someone might not get a back-on-the-freeway route.

It has been established that the alt name circumvents this concern.

So let's see if the examples that have been fished up demonstrate improved behaviour with that.

As I said, we can go the opposite route and remove it from Toronto freeways and see if the behaviour is affected negatively.

Sure, except that drivers also report things on the opposite side, so including the cardinal can actually create an erroneous report. Truthfully, the report probably isn't that much better (in notifications, Twitter, etc.) with the cardinal - Hwy 401 isn't a short road.

I come back to the fact that this doesn't appear to have negatively affected Vancouver area, despite not having had cardinals for quite some time.

I'll come back to the fact that the official name of this road is going to be "Hwy 401" - the cardinal is a descriptor, not part of its name.

Nagamasa wrote:

Note that the trailing N, S, E, W cardinal direction indicator is used for numbered highways and interstates which are split into two 1-way segments, per the guidelines.

So, any freeway, should be divided and have cardinal directions.
(Wild conjecture: perhaps that's why we always divide freeways too, so that this very manoeuvre can be allowed.)

Also note the "no cardinal directions" thing seems to only be in Western Canada, west of Thunder Bay, Eastern Canada seems to be doing the opposite.

Well, we need to reference alexs001's comments about Hwy 97 N. This was originally divided into one-way segments initially, and the name was wrong (i.e. southbound was named Hwy 97 S). Undividing of this left us with a correct solution, though also precluded u-turns.

How about ring roads, or other non-linear freeways (QEW)?

As it's done in Toronto, the engineers have avoided using cardinal directions altogether, and simply signed the highway consistently with the next control city (Toronto, Hamilton, Niagara, Fort Erie). This is how it is currently mapped in Waze as well.
Anthony Henday in Alberta, is a ring road. But Albertan human factors engineers are not stupid--the highway seems to be consistently signed according to the cardinal direction that you are currently travelling in. We can name it the same.
(Heck, in Japan, ring roads and ring metro lines are signed with clockwise and counter-clockwise directions!)

Well, actually it's not. If you're on Anthony Henday on the north part, headed counter-clockwise, you're westbound (and the signs reflect that). If you're on the south part, headed counter-clockwise, you're eastbound (and the signs reflect that). The issue is that it's not a perfect square. It's really closer to an octagon. And they don't sign the cardinal direction as NW or SE. It's less confusion to just leave it off.

As a side note, the other thing I've noticed from time to time is that Waze seems to consider the frequency of a streetname in deciding when it's going to display it, and with what prominence on the screen.

So having two segments named "Hwy 1" results in a higher prominence than one each labelled "Hwy 1 E" and "Hwy 1 W".

Those two test cases are appropriate, but I think you misunderstood me about the alt-names.

I'm not arguing for implementing the alt-names all around -- I'm suggesting we use that as the manner to test whether it it BDP preventing the turnaround (as BDP respects the alt-name and you wouldn't be taking a "different" road, but staying on the same one for the entire u-turn), or whether it's another Waze routing factor that relegates the turn-around option to #2 in some of the cases we've found.

Part of the trouble I'd like to put out there with your testing approach (the negative case) is that it may erroneously prove you wrong. Waze may still choose the turn-around option (as it does on the cases I tried in both Edmonton and Vancouver). I had only put this out there as an approach that was as negatively impacting as the one you wanted done.

Perhaps. I've not necessarily been following that (eg near Lake Louise, AB)

Yes, please do.

It's significant enough that we probably want to consider a way around it.

I'm not sure we want to go the way of cluttering it by including cardinals, though the work of alt-naming all the ramps and overpasses (and also keeping those alt-names there from under-educated editors) may be more than it's worth.

I'm disappointed to have been proven wrong, but accept it.

There are two main arguments FOR cardinal directions:

First, they are the standard in the US. Road shield rules seem to work fine there (although I haven't personally seen the complexity of the rule(s) required to make this work -- perhaps someone could look those up for us all to see and evaluate).

Second, is to improve the functionality of Big Detour Prevention, which seems to use road name as a key criteria: "It is name (primary or alt), detour length, and road type group pre-detour and last segment of detour." (quoted from the CA Editors - General Discussion GHO, user Patti on Dec. 6 at 1:06PM).

The key BDP scenario that we would hope to "fix" with BDP would be a user traveling in the wrong direction from their destination on a divided road (most common cause is a missed exit or possibly starting a route after already entering the highway in the wrong direction). The discussion is that BDP without cardinal directions would prevent the most logical route (get off at the next exit, turn around, and get back on the road in the other direction to return).

So, at this point, we are looking for any real-world examples where the road does not have cardinal directions, and BDP is clearly preventing the turn-around-and-go-back. Once/if we have some good examples, we could then try adding the cardinal directions to see how it changes the BDP.

I'm undecided until I see the examples stated above.

@Nagamasa: Thanks for the examples. However, it would probably be better not to move the origin to a ramp, but actually to be about 1/2 to 1 KM past the "missed exit" (on the main highway segment). This more closely simulates the app has just recognized a missed exit and is talking to the routing server to recalculate. Putting the origin on a ramp is forcing a solution which isn't really the scenario we're discussing here.

Also, we shouldn't apologize for using an example on the urban border. This is probably the scenario where you will lose the most time due to this issue (since exits often get farther apart in rural areas). If it's 10K to the next exit and Waze won't route you on a turn-around because of BDP, you're going to lose a lot more time.

As stated by others, my main objective when using Waze is to save time and avoid traffic. If this BDP glitch is causing me to lose 3/5/7/11 minutes, I would like that situation to be rectified if possible. If I wanted to take my time or get stuck in traffic, I'd still be using my Garmin... [drop mic]

One more thing regarding the "hack" label -- I don't disagree that using cardinality for the sake of fixing BDP is a hack, but at least it still has some redeeming qualities for users & editors (visually distinguishing direction of travel).

Adding alt names to the exits and crossovers is way more hack-ish -- I can't see the alt name on the crossover helping/pleasing anyone.