Wow... all of this sounds like a very promising and exciting move from the stringent KJV-only versification system currently in place to a much more lenient methodology for handling the texts.  It seems to me that some of the problem could be to maintain the current system of Keys that are in place and cause those which currently are not to become wrappers of a base class other than SWKey.  It would seem most natural to me to have them all be descendants of SWTreeKey, since all texts are able to be represented as Trees.  Then an SWVerseKey could be a TreeKey which has the ability to parse abbreviated book names and chapters and ranges.  It might take some difficult logic to work on a range if the Bible text is represented as a TreeKey and the user wants something like John 2:12-3:14 but it shouldn't be terribly difficult.
<br><br>I have no concept of whether that would be beneficial or helpful, but it seems conceptually useful for other texts (I keep thinking of modern commentary structures which include introductions to paragraphs, chapters and books as well as verse-by-verse commentaries underneath of those structures - personal commentaries might enjoy that structure).&nbsp; Also, maintaining the other keys as wrappers might mean that you could maintain compatibility, even for new texts like that LXXM which you are talking about, with existing front-ends.&nbsp; They would just access the text through a VerseKey as they always have and the wrapper of the VerseKey would be forced to work out the logic of incrementing or changing keys.
<br><br>--Greg