If we can create a mapping for Robinson codes to something that is better (human readable and easy to search), then we can use the mapping w/in JSword to provide a better user experience.
Basic thought, the user would see the new codes or a decoding of these codes into their language (or the default, if there's no such translation). They can search these codes either directly or via a wizard (what is done would be a front-end choice).
It may be that the underlying module uses the old codes. That'd be ok. Not ideal. The search would reverse the mapping going from the new codes to the old codes and use that to search the module. Likewise, when presenting the module, the old codes would be replace with the new codes. This would be a process of normalization, which we do currently for Strong's numbers.
We may want to explore the idea of a module sidecar. On various occasions, I've wanted finer grain information regarding a module. Basically, we'd maintain a separate conf for the modules. It'd contain information regarding thing like: user provided font info, unlock keys, type of Strong's numbers per testament, type of morphology per testament, .... Any program can set a value into the sidecar. This info would be read into BookMetadata and would be available for all programs. If a program doesn't know what to do with it, it'd ignore it. It would be good to communicate and document these new values. Automatic behavior that's added to JSword would need to be discussed.