HotDeployは有効な状態

対処しました（r1387）。

具体的には、リクエストを受け取ってからリクエストの処理が終了するまでの間にセッションにsetAttributeされた属性とセッションからgetAttributeされた属性について、リクエストの処理が終了した時点でセッションにsetAttribute()しなおすようにしました（setAttributeされた属性についてもsetAttributeしなおすのは、setAttributeされた後にオブジェクトの状態が変更されうるから）。

おっしゃることは分かりました。

後は実現の方式ですね。@Inに対応する@Outが存在しない場合に@Outがあるかのように振舞うようにするとして、
それを「常に」そうして良いのか（Injected Objectへの変更をフレームワークが検知できないため、「変更があった場
合のみ」ということができないので）、「全てのScopeについて」そうして良いのか悩んでいます。おそらくSessionScope
の場合は「常に」上記の振る舞いで良いと思いますが、そういう振る舞いをしない方がよいScopeもあるかと思います
（例：RedirectionScope）。

というわけで、良い方法があればアドバイス下さい。

アプリケーション間の同期までは求めていませんが、Outjectionされるタイミングで、Injected Objectの状態変更があった場合は、セッションに格納される（シリアライズされる）オブジェクトをリフレッシュ（上書き）する程度のことはやったほうが良いと思われます。

これは、インジェクションされたインスタンス（への参照）は、セッションに保持されているインスタンスそのものであるかのように見せかけるということです。この対応があれば、@Outを記述する目的が以下の2つに絞られるため、コードの記述量が減り、Pageの設計意図が明確になると思います。
　・新たにオブジェクトを（セッションなどに）格納する場合
　・格納されているオブジェクトを削除する場合

逆に、セッションをEIS層と同じ感覚で、InjectionされるオブジェクトはMutableであっても、「シリアライズされているオブジェクトのコピーである」という思想であれば、このIssueはcloseしていただければと思います。

これは、クラスタリングなどの場合にセッションスコープのオブジェクトの変更を別アプリケーションインスタンスに
通知できないということを指していますか？もしそうならおっしゃるとおりです。ただ、現状のYmirはクラスタリングを
想定した作りになっていないため、この対応をしてもクラスタリング環境では動作しません。（将来的にはクラスタリ
ング環境でも動作するようにしたいと思っていますが）