「飛鳥」にも、当然打ちづらい手はある。

　どうしても、「シフトを押しつつ逐次打鍵できる」という構造が原因で発生する「シフトミス」だけは無くしづらいですな。
　たとえば「あすか(←dk l)」が「あすま(←dkl)」になってみたり、「はいれつ(ok →ij)」が「はいれん(ok →i j)※[→iの後にキーを離してしまうくせがあるので]」とか。
　…要するに「2文字ずつなどに区切って打てば問題ないようなもので引っかかる」例が気にかかります。

　もっとも、これを気にして「逐次打鍵を無効とする」と、飛鳥の面白さ(逐次打鍵によって得られる打鍵コストの低さ)が失われてしまって「NICOLAとあまり変わらないかも…」となる気もしますから、もちろんそのまま使うのがもっともよいとは思いますが。
　#実際問題として、逐次打鍵がデメリットとして発現するのは、(頻用されない)固有名詞絡みがほとんどです。
　#それ以外の「言葉同士をつなぐ言葉」に関しては、特に気になる不都合は見あたりません。

　結局は、普段から「何気なく言っている(/書いている)言葉」を、「何気なく打鍵できるようにする」って事に注視した結果なのかも。
　(相手に聞き取ってもらうためにと)一文字/一区切りずつ丁寧に発する言葉については、打鍵速度が多少遅くなってもかまわない…でも、何気なく一纏めに発している言葉については、打鍵速度が遅くなってしまうと(打鍵速度が遅いことに対して)いらつく原因になる…。
　こんな言葉の特性をみれば、「どんな言葉を打つときであっても同じコストで打鍵できる」配列よりも、「早く打鍵できてほしい時だけローコストで打鍵できる」方が、「仮に基本的な打鍵速度が遅くとも、配列側で何とか対処できる」分だけ有利かもしれません。

　飛鳥の「部分的には早く打てる」事に対する解りづらさってのは、この「言葉をつなげてみないと、連続シフトかどうかわからない」ところにあるのかも。
　AZIK/ACTならば、大抵は[ai/uu/ei/ou/ann/inn/unn/enn/onn]の拡張位しか使わないから、まぁ音読みの漢字とかに使えばいいってのは想像可能です。
　しかし、飛鳥の場合は「実際に打ってみる」か「打鍵例を書いてみる」か「配列表を片手に考える」以外には、そういう「ローコストで打鍵できる手がある」って事を理解し辛いんですよね。

　うーん…ここは「打っているうちに解るでしょ。」としか言いようがないのかなぁ…それとも2文字連接の頻度データから逆引きして提示するべきなのかな(…って、それは説得力がなさすぎるから却下かも)。