My wife is going to be in Taiwan for a few weeks to visit her family. We already have an international calling plan, but I asked around to see if anyone knew of anything cheaper, since we'll be calling a lot. Franci Penov (among others) thoughtfully replied. Here's an exerpt:
Since they specialize in low prices for Bulgaria, their rates for Thailand  are somewhat higher - $0.11 per minute if you call Bangkok, between $0.16 and $0.27 for the other cities and $0.365 for cell phones. If you live in New York and use their local number, the prices are with about $0.02 less.
There might be other cheaper phone cards that specialize in low pricez to Thailand that offer even better prices. :-)
You'll notice that he thought I said "Thailand" rather than "Taiwan". Hey, they're both Asia, right? An honest mistake. But being the smartass I am, I responded:
I'm not sure my wife would appreciate me calling Thailand while she's in Taiwan. ;)
"Ha ha," I thought, "I'm so funny!"
Then I got Franci's response, which made me realize that I'm clearly only bush-league funny.
I agree that the problem you state below can be a big issue for some of our customers. However, that doesn't mean our feature implementation is not right. Let's me expand on this little bit more.
The original problem we wanted to solve was how to call in Taiwan without paying much. The implementation cost for "call cheap any location in Asia" feature is essentially the same as the cost of implementing the "call cheap Taiwan" scenario, so the management decided that we should implement this feature instead, as it will address broader set of customer scenarios. We had to provide a default value for the particular location to call in the case the customer does not provide one; we choose the default value of 'Thailand', but of course this value can change after the proper usability study is conducted by the UE team. Our current implementation of this feature is the correct although probably not the most optimized one, as specified by the feature design.
If we need to add the feature "talk with the customer's wife", the PM team should write the appropriate feature design document. One possible issue with such feature will be how to find the location of the customer's wife, so we might need to design this feature as well. I can write small architecture document describing tri-tier distributed solution for this problem after that which will use as underlying way of communication the "call cheap any location in Asia" feature (provided that the customer's wife was located to be in Asia) or the corresponding "call cheap any location in Europe" or "call cheap any location in Africa" features (although these two are not implemented currently).
I will reflect the necessary time for the architectual design of this feature in my schedule. The cost of the actual implementation will be reflected there as well, although at this point i can provide only SWAG and the actual costing will happen after the architecture design review.
As for the particular bug you are refering below (customer's wife not being happy) - there is an easy workaround the customers can deploy - don't tell the customer's wife that the customer called somebody in Thailand. Of course we all know that security through obscurity approach is not in general favored; however it will have low impact on the customer's TCO and as such it should be recommended unless the customer's wife is known to implement active data mining on the customer's call logs. In future we will need to add new feature - role-based security for the access to the phone line logs and the customer's bank statements. Given it's cost though, we will not be able to add it to our current product version and will have to make it v.next feature.
I hope this explanation presents clearly the current state of the product and our future plans and addresses your and customer's concerns. If you have further questions/comments on this particular feature or any other feature in our product, please do not hessitate to contact me.