I made these blank layout charts that I thought might be helpful for anyone working on an alternative version:

Thanks for the kind words! 

I call what you're referring to as a "fragmented chord;" when the user intends to type a chord but progresses too quickly and hits the individual elements separately instead of simultaneously.  It happens sometimes, but since the output is based on the release of keys, "step-on" errors where the user presses two keys simultaneously instead of separately are more common, especially as the user gets more proficient and starts typing more quickly.  An example of a step-on error similar to what you described above would be for the user to intend to press an A followed by an R, but getting the output W instead. 

Both of these kinds of mistakes are dealt with by an autocorrect procedure; when the program receives input, it checks it against a dictionary before proceeding.  If the text, as entered, is found as part of a word, everything remains the same.  If not, the program attempts substitutions based on the potential errors that might have been made as either a step-on or a fragmented chord error. 

In the above example, let's say the user is typing the word "art."  If the user steps on the A and R keys (i.e. pressing the R key before completing the release of the A key), the program will output the letter W.  As is, that's fine because there are plenty of words that begin with the letter W.  However, if the next input received is the letter T, the program will see the letter combination "wt" and recognize that an error has been made.  It will split the W into its component parts (A and R) and form the word "art," then look it up in the dictionary and confirm that it was what the user must have intended (since there are no other potential formulations for the given input), and change the output accordingly.

Similarly, if the user is intending to type the word "wet" and fragments their first chord, the resulting input ("ar") will remain unchanged when the user enters the E key ("are") but will consider alternatives when the user enters the T key, since there aren't any words in the dictionary that begin as "aret".  The choices it has are "wet" (by combining the first two letters into a chord), "azt" (by combining the middle two letters into a chord) and "arv" (by combining the last two letters into a chord), so it will presume that the user intended the word "wet" since that's the only viable option.

The autocorrect isn't infallible; for example, if the user types the word "are" when intending to type the word "we," the program won't be able to recognize that an error has been made.  But I haven't found that to be a major issue - at least with the ASETNIOP configuration.  And of course with longer words, the ambiguity decreases and it's easier for the program to recognize the true solution.

Here's a little video that shows how the process works with the ASETNIOP layout; the process for Colemak would be identical but would use a different set of codes to determine the output alternatives:

www.youtube.com/watch?v=5OHXk0DlZkc&feature=youtu.be

I don't think that any alternative will beat a standard keyboard (regardless of layout) for speed and simplicity.  The intention of this particular method is to allow touch-typing to evolve away from an actual physical keyboard.  Ultimately ASETNIOP is designed for devices like the iPad, or cellphones equipped with a motion sensor similar to the Magic Cube device that Cellulon makes (without needing the laser), or even a set of sensor-tipped gloves.  The idea is that without tactile or visual feedback, it's much easier for a user to control the sequencing of 10 input points than the positioning of 26+ input points.  So I'm sticking with ten points - the computer can track which fingers are coming down, and the user doesn't have to worry about the physical location of the fingers as long as they don't drift a ton.  Everything else that's been developed so far (Swype, SwiftKey, touchscreen keyboards) requires some kind of visual guide or else things go pear-shaped almost immediately.  ASETNIOP is supposed to take things a step further; touch-typing without a physical keyboard and without needing to visually monitor the input stream.

Yep, that's me in the video and so far I'm patient zero - I'm only just now discussing it publicly because I wanted to file for IP protection on some of the processing methods, which should be applicable to *all* chorded keyboards, not just this particular layout.  I've been developing it for the last couple of years, so it's hard for me to say how long it takes for a new user to reach proficiency - I'll be conducting a few focus groups this summer to try to get some idea. 

In the meantime...I went ahead and coded a Colemak version using the layout shown above: www.asetniop.com/colemak.html. 

Anyone interested is very welcome to give it a try - none of the autocorrect features I described are active, but you can sample the layout and see if you agree with my placement or if you've got suggestions on which keys/chords should be moved.  I'd be very grateful for the input!

Will take a while to digest this!

Interesting that you mention key release, I've wondered before if it would be better for a normal keyboard to work on this basis. Would it lead to a better typing technique?  Or is it more difficult?  I like the idea of resting the fingers.

Yeah, it makes more sense now. As for your latest question – I wouldn't say it's much harder, if at all. I think it's one of those things which even if troublesome in the beginning, you get used to it and then forget it ever bothered you.

My experience with xkb is steadily growing. :)

The only kind of chording I've managed to implement is an Extend layer that maps modifier levels 5+; I use the Caps key for that (see my Big Bag topic linked to in my sig). Also, you can use the four available groups and switches to the next and last groups for two more mapping layers (so I could use a mirrored and a Greek phonetic layout to enhance my basic one for instance). This means you can make three more modifier keys and do lots of fancy stuff with them, but it's not true chording.

I don't think true chording is possible in the current state of the XKB.

Thanks for giving it a try!  Were you having a problem with the semicolon key (and associated chords)? There was a bug in my code; apparently Firefox uses a different code (59 vs. 186) and I've gone ahead and fixed that.  If it's something else, let me know and I'll get it sorted out.  I'm actually close to having a Colemak version ready for iPads/tablets, which is VERY exciting (at least to me; hopefully it will be to Colemak users too!) and I'll post a link to it once it's available.