My coding experience, what there was of it, is some 30 years out of date, so take the following with a grain of salt when it comes to how it would be implemented.
It looks like the JNC search engine searches specified fields using a strict character by character match, but allowing anything beyond the final character of the search string to be considered a match when compared to the database contents.
If the search string is five characters, it'll compare the first five characters of the proper field in all relevant records and so long as those five characters match return that record as a 'hit'. A blank character, or lack of characters entirely, does not count as a match, so a five character search string will never return a four character entry.
Thus, a search for Toshizo will return both Toshizo and Toshizou, while searching Toshizou will exclude Toshizo as it doesn't have the requisite 'u'.
All the possible solutions I can think of require a pre-filter that search strings pass through before actually searching the database.
I'm working on the presumption that all searches funnel back into the same search engine after passing through the pre-filter, as there are no permanent relations being established within the database proper between variant spellings. [the database structure itself remains unchanged].
A search string gets entered, and is compared to a list maintained in a pre-filter.
If the search string finds a match, it truncates the search string to one which will pull up all variant spellings based upon information stored within the pre-filter [either using a truncate command if the language supports such, or saying "use this stored search string instead"].
It's a non-trivial task to set up and maintain such a thing, which makes it a rather low priority in comparison to other web site improvements under consideration at this time.
