Event-Drivenな状態遷移を管理する目的でXhwlayを作ったが、Webアプリケーションで使う上で一点だけ未解決の領域があります。
それはブラウザの「戻る」ボタンです。

「戻る」ボタンが押された時ですが、サーバーがクライアントキャッシュが効くようなHTTPヘッダーを送信していれば、ブラウザはHTTPリクエストは送信せず、自分で保存していたキャッシュを表示します。もしサーバーがキャッシュ無効なHTTPヘッダーを送信していれば、ブラウザはHTTPリクエストを再送信するでしょう。

ところがXhwlayの場合、「今どのページを表示しているのか」をサーバー側で保持することになります。
５画面に分かれたウィザード形式の入力フローを想定し、例えばユーザーが画面４まで進んだ後に画面２まで「戻る」ボタンで戻って入力をやり直したい、と思っても、Xhwlayの管理上はユーザーが今居る画面は画面４のままです。従って、画面２まで「戻る」で戻ったユーザーが入力値を修正して画面２の「次へ」ボタンをクリックしたとしても、Xhwlayの管理上では画面４に対して無効なイベントがリクエストされ、おそらくは無視され、ユーザーには画面４が表示されてしまいます。そのため、「前の画面に戻って入力をやり直す」イベントやそのためのボタンをアプリ側で用意する必要がありました。

これをどうやって解決するかですが、以前触ったAppleのWebObjectsにヒントがありました。
WebObjectsではURL構成要素の最後、fragment("#"以降)を使い、画面の履歴を裏側で保持しています。正確には画面表示に使う値をオブジェクトとして、fragmentの値に紐づけることが出来るようになっていて、WebObjectsが自動で管理してくれます。
これと「キャッシュ無効」を併せると、「戻る」ボタンでURLが再リクエストされると、そのfragmentから以前の画面表示に使われた値を取り出すことができ、以前の値を再表示可能になるという仕組みです。
・・・えっと、確かそんな感じでした。大筋は間違ってないと思います。とりあえずfragmentを履歴管理のIDとしているアイデアは間違ってないはず（;´Д｀）。

もちろん、無限に履歴を保持することは出来ないので、上限数も設定出来るようになっていました（たしか50とかそれくらい。50ページも「戻る」で戻るのはレアケースなので実用上はこれでOKではないでしょうか。それ以上越えると、「これ以上戻れません」的なページが表示された記憶があります）。

つまり、「巻き戻し再生用のID」を用意すれば解決出来そうです。格好つけて「セーブポイント」と名付けてみましょう。この「セーブポイント」にその時点での「今居るページ」を保存しておけば、巻き戻しも出来るようになります。
さらにXhwlayの場合、ページフロー遷移中にフロート紐づけたいデータを「Bookmark Data」として保持していますので、これをその時その時の「セーブポイント」に履歴として保存しておく。
こうすれば、「戻る」で任意の「セーブポイント」まで戻り、その時点でのState, Bookmark-Dataに巻き戻し、なおかつそこから進め直す事が出来るようになる・・・筈、です。多分。

「セーブポイント」についてはBookmark-IDとは別でHTTPリクエストに含ませることになりますが、fragmentは避けたいです。JavaScriptや画面ナビゲーションで"#"以降を使いたい場合も有ると思いますので。
Bookmark-IDの後ろに、"."とか","で区切ってセーブポイントのIDを入れておくのが分かりやすいと思います。

しかしXhwlay単体だとやはり使いにくいです。毎回アプリ毎に作り込みが発生してしまう。
そろそろ、XhwlayのアイデアをCakePHPやSymfonyなど他のフレームワークに、プラグイン等の形式で移植するべきかも知れません。