Hi M S,
I just spoke with the US support analyst who was working with the Canadian support analyst you were working with. You should be getting this information via your case but I wanted to respond here for other users who may view this thread.
The bug that you were attached to is not actually relevant to your particular use case. That bug is specific to geocoding ONLY the postal codes in Canada (not a full street address), and then only when zoomed in beyond a specific extent.
First a quick note about Canadian Addresses. Like US addresses, they are technically split into two sections. In the US we call the two parts Zip+4 (12345+6789). In Canada they're called Forward Sortation Area (first three digits, A1A) + Local Delivery Unit (second three digits, 1A1). In the Esri datasets, we have two fields; one called Postal (which for the US is the 5 digit zip code and for Canada is the FSA) and one called PostalExt (which for the US is the zip+4 and for Canada is FSA+LDU).
Regarding BUG-000086454, when a user is zoomed into certain extent in the Map Viewer the request that's sent to the World Geocoding Service includes location and distance parameters, so if there are two similar addresses returned by your request the Map Viewer will zoom to the one that's closer to where you're currently looking in your map. If you geocoded M3C 3R8, you might be closer to the centroid of M3C than you are to the centroid of M3C 3R8, and therefore the Map Viewer will return M3C instead of the "full" postal code. That's the very basic underlying issue behind BUG-000086454 but that's not what you're running into.
You're geocoding an entire street address ("1000 Bay St, Toronto, Ontario, CAN"). When you're geocoding to the street or house level you'll be getting responses from our point address or street address locators (not the postal or postal+ext locators like the workflow from BUG-000086454). By default, these locators will return only the Postal field I mentioned above, not the PostalExt field.
Since the Postal field only includes the first 3 characters of the full Canadian postal code, this means what you're seeing is expected behavior. However, from a practical standpoint it's definitely more common to use the full 6 character Canadian postal code than the 9 digit US zip code, so I can definitely see room for improvement here. Therefore, I've asked the analysts you've been working with to log an enhancement request to deal with this specific Canadian use case. They should be providing you with the ENH code when it's been fully written up.
I hope this helps clarify the behavior you're seeing. Thank you for calling attention to this issue!
