So the issue with this last example isn’t exactly a bug.
0678655524 is found with 0248655524 because internally we store the phone number in 2 ways: the international number (as it is inserted) and a local number (with international prefixes removed, where available). In this case 0678655524 is recognized as an international number with international phone number identifier 0678 (a leading 0 is a common in Europe, Asia, Australia and New Zealand as the identifier for international phone numbers and 678 is the international dialing code for the island state Vanuatu).
The 0678 is stripped from the front of the number, leaving 655524 as the local phone number. Similarly, your stored phone number 0248655524 is stored both as 0248655524 (international number with 0+248 recognized as an international phone number for Seychelles) and a local phone number 655524, which matches your search term’s local phone number.
Is this a real use case you’ve ran into or did it just come up during testing? 2 phone numbers matching (minus the international code) in 2 different countries has been a very rare case so far.
The reason why this logic exists is so when users store an international number, they can still search for it using the local number and the other way around. Being able to search for the same number with a different country’s international prefix is a minor side effect of it.