Bug: fail to display properly, consistently: separate (different, independent) contacts but which share same/overlapping phone#s...

[jwmh]

For example: Three people work at the same company, Alice, Bob, Charlie . They have different extensions at work, but the same original 10digit telephone number. . Sample:

Alice Work Phone: (555)555-5555,,,001#

Bob Work phone: (555)555-5555,,,002#

Charlie Work phone: (555)555-5555,,,003#

The above examples illustrate how I like to use my Contacts directory.

Another example is calling different departments within a large corporate, or goverment, organization:

I need to:

• call the main#,
• select 1 for english,
• enter my state medicaid ID# (a nine-digit string),
• press the pound or hash sign,

And then.... If i am calling tech support (because their web portal has bugs), Then i press 2, Then i press 7 to speak with someone

Or... If i am calling to change my health network of providers, I instead press 3,

Or... If i am calling to update my contact info, I instead press 4, Then i press 1

Example: Oregon Health Plan - tech support: 888-888-8888,,1,,000000000#,,,2,,2

Oregon Health Plan -- change address/contact info: 888-888-8888,,1,,000000000#,,,4,,1

These fail to show up properly as multiple separate entries.

Another case:

Contact David: Workline: 555.555.1234 (He is the receptionist, so sometimes i just press 0 and wait)

versus

Contact Emma: Cell: 555.555.5555 Workline: 555.555.1234,,002#

In the case of Emma... ... Her second telephone# -- the workline (shared w david, but a different extension) .... ... Does NOT display, when i view/open her contact card. . However, if i hit "Edit,
Then i do see the second number i entered for her. . But if i am only viewing (not editing), i cannot see it.

#####

*****

TL:DR;
These dont show up properly as separate contacts.

Something about how Simple Contacts **parses*** 
and stores, assigns in a database...

... Something about the algorithm seems inadequate for differentiating / telling the difference  between these use cases.

****
This may be related to Issues 623, 620, 612, and others' reports.