Last 7 digits of contact phone numbers confuse Synegy?

Question

Hi -- I have posted a more detailed description of the issue (including how I came across this issue) at:
http://forums.precentral.net/palm-pre/213995-weird-sms-addressing-feature.html
Basically, my issue is this:
Background:  All phone numbers in my contacts list are 10 digit U.S. numbers with (ABC) DEF-GHIJ format.  99% of my Synergy contacts are from Google with just 10 or so of 700+ coming from my company's Exchange.  To my knowledge, I currently DO NOT have multiple contacts with the same last 7 digits DEF-GHIJ, but during my personal testing for this issue, I did create a dummy contact record (see below)
Issue(s):
*  Let's say I have a contact record for my wife which has her mobile # as 617-DEF-GHIJ.  If I begin a new SMS (using phone # to address the SMS rather than her name) to XYZ-DEF-GHIJ, where XYZ is ANY random 3 digits....555, 567, 345, etc... then the contact field will update to populate with my wife's name after I move the cursor focus to the SMS body text.  I have not actually tried to complete an outbound text this way, but I believe the text would actually be sent to the XYZ... area code and not actually to my wife's 617 mobile # (I assume this based on the phone call analog below)
*  Same issue with phone # dialing:  I dial XYZ-DEF-GHIJ instead of my wife's 617-DEF-GHIJ.  On pressing send, the phone connection screen show's my wife's contact name and her contact photo (along with the incorrect XYZ phone number).  However, the call is routed to the incorrect phone #.
*  Finally, I added a test contact "Joe Test" with a phone number of 555-DEF-GHIJ.  In doing so, Synergy immediately linked the new Joe Test contact as second profile under my wife's contact record.  It also changed her name in my SMS history to now reflect Joe Test rather than my wife's name...  I didn't realize this happened until I saw that Joe Test had sent an SMS asking me to bring home some milk.  I then unlinked the Joe Test profile from her contact record.  (leaving him in my contact list as his own separate contact entry).  However, even when unlinked from her profile and with not exactly the same phone #, her full SMS history still indicated Joe Test and not my wife's name.  Only after I deleted the Joe Test record from my contact list was my wife's photo and name correctly re-attached to her SMS history (this might have only happened after she sent me a new SMS message and not immediately).
Clearly, this was some intentionally implemented feature to support 7-digit dialing or the synergy contact linking gone awry.  Also, clearly it's not likely to greatly impact a lot of people, since a user must have two contacts with the same 7-digit phone number (within a 10 digit phone record entry) to really be impacted.  However, it seems to be a significant enough problem that it should be addressed in a future update. 
Please advise if my issue report is unclear or cannot be repeated at Palm.  I don't have access to another WebOS device yet, but I am nearly certain that this is not an issue solely related to my Pre.  I'm happy to help debug if you cannot repeat the issue.
best,
John Greenaway
Post relates to: Pre p100eww (Sprint)

Answer 1

Still there, and definitely a bug
Presumably as part of the Synergy implementation, the Prē apparently considers any telephone number string, including multiple numbers associated with the same contact, ending in the same last seven digits to be the same.
Unfortunately, this is not as unlikely as the original poster supposes: even discounting the "birthday paradox", reuse of PINs--especially of six or more digits, followed typically by '#'--makes the problem especially obnoxious for multiple, personal voicemail numbers embedded in a single contact entry: all but the first is hidden, except when editing the contact.
The only workaround seems to be to pad with trailing, timed delays ('t'), so that the comparison will fail: since the telephone app permits "dialing through" a delay, it doesn't interfere with use of a service, but is highly counterintuitive!
egr