For the sake of others playing along at homehttp://www.rikai.com/library/kanjitables/kanji_codes.sjis.shtml
The same also applies (and would be desirable) for EUCJP so might as well do that too http://www.rikai.com/library/kanjitables/kanji_codes.euc.shtml
Most such editors with claims of support tend to do fixed length stuff, hence the turning to mush (and back again) when an 8 bit (or odd multiple thereof) section appears in the mix, possibly before going back again.
Input wise it only gets worse, especially if you care about ROM hacking stuff as most game implementations of shiftJIS don't do the unicode support that the PC standard technically employs. Roman (and many other) characters are available in the list above, and most games needing Roman characters (and basic hackers looking to do something quick) will do the same.
Even big boy Japanese/Asian word processors like JWPCE/JWPxp https://mijet.eludevisibility.org/JWPxp/JWPxp.html
have a separate input button for these to force it into that.
Nobody should be editing anything for real in a hex editor though -- basic analysis, search, find-replace, simple functions (flip, shift...) and a number of things you can reasonably type as bytes (or copy and paste I guess) being what they are typically held as being for. To that end if you did want to just grab the data from rikai (or even the tables here) and stuff it in as an extra encoding at forced 16 bit lengths then what would do. Anybody needing such a shift will probably then pick a suitable point to delete a byte to shift what they want to see into view as it were. If you wanted to stick a force decode from next 8 bit alignment button similar to the ideas of the word processors mentioned in the line above then that would sort most people out.
If you did want to get more advanced then most things are going to be at least four characters long and only start with 8,9, E or F (mostly 8 and 9 as well) so you could try some kind of probabilistic thing with shifts. While it would be nice I sense this would be something of a departure from the simple but solid thing that has made HxD such a hit over the years -- I can't see how you will do it without some kind of radical retooling of the highlighting command (granted most I have seen try it just have some kind of disconnect between them).
If you care to court ROM hackers for some reason then a simple shiftJIS and EUCJP to the decode options will do you well, basic custom table/encoding support would make you a lot of friends, we have options for relative search but if you wanted..., your one time competitor in mirkes.de tinyhexer* has a nice distribution analysis (though I like hex workshop's more) and a list of shifts, rotations, boolean logic and flips on par with something like hex workshop or 010 will make you endless ones. I forget which one it was but I did also see the option in a hex editor once to flip individual bits by way of a checkbox in the top right of the toolbar.
*many years ago I did a shootout of all the hex editors I could find. hxd, mirkes.de tiny hexer, https://sourceforge.net/projects/hexplorer/
and xvi32 if you counted the scripting combined made something as potent for most of my ROM hacking purposes as hex workshop (and possibly 010 editor). For ROM hacking purposes like the tables mentioned above then we had a few more on top of that.