Kuwataさんが、Pythonのモジュールローディングを細工するワザを書いています（http://return0.info/note/2012-05.html#id2012-05-14 http://return0.info/note/python_module_isolation.html）。これは、Catyのアプリケーション、ライブラリ、コマンドなどの概念と構造を整理し、それを実装するために使った方法です。
Catyでは、プログラムを「アプリケーション」と呼ぶ大きな単位にまとめています。Catyのランタイム内で複数のアプリケーションを実行することができます。appA, appB, appC というアプリケーションがあると、それぞれに appA/, appB/, appC/ というディレクトリが対応します。ひとつのアプリケーションに関連するすべてのファイルが、対応するディレクトリの下に置かれます。
今現在、実際のとあるアプリケーションのディレクトリは次のようになります*1。
$ pwd
/c/Users/hiyama/Work/ProjectCaty/dev/main/root$ ls -l
total 62
-rw-r--r-- 1 hiyama Administrators 42 Aug 11 2011 _manifest.json
drwxr-xr-x 2 hiyama Administrators 0 May 9 20:05 actions/
-rw-r--r-- 1 hiyama Administrators 0 Jul 22 2011 app.log
drwxr-xr-x 2 hiyama Administrators 0 Apr 20 15:06 behaviors/
drwxr-xr-x 2 hiyama Administrators 0 May 11 16:36 commands/
drwxr-xr-x 3 hiyama Administrators 0 May 9 23:56 data/
-rw-r--r-- 1 hiyama Administrators 0 Jul 22 2011 exec.log
drwxr-xr-x 2 hiyama Administrators 0 Jul 22 2011 include/
drwxr-xr-x 2 hiyama Administrators 0 Jul 22 2011 messages/
-rw-r--r-- 1 hiyama Administrators 12256 Apr 26 14:44 performance.2012-04-26.log
-rw-r--r-- 1 hiyama Administrators 15952 May 5 13:21 performance.2012-05-04.log
-rw-r--r-- 1 hiyama Administrators 4203 May 13 13:28 performance.log
drwxr-xr-x 3 hiyama Administrators 16384 May 11 23:46 pub/
drwxr-xr-x 2 hiyama Administrators 4096 May 11 16:35 schemata/
drwxr-xr-x 2 hiyama Administrators 8192 May 11 22:43 scripts/$
プログラミングの観点から重要なサブディレクトリは schemata/ と commands/ で*2、それぞれにスキーマ定義ファイル（.casmファイル）とコマンドの実装ファイル（.pyファイル）が格納されています。
アプリケーション達は原則としてお互いに分離されています。しかし、アプリケーション間には親子関係があり、子からは親の持つ資源が可視で利用可能です。
大筋は以上のとおりなのですが、「資源」とか「可視」「利用可能」などにあまり厳密な意味が与えられていませんでした。最近、アプリケーションを階層化する仕掛けを整理しようと思っています。親の持つコード資源（実行可能なナニカ）は子から見えて利用可能なほうが便利です。一方、データ資源は親子でも隔離しておいたほうがいいようです。とはいえ、コードとデータの区別も微妙なものがあって、データと密接に結びついたコードもあります。例えば、Webページに紐付いたスクリプトとかです。
もうひとつ大きな問題は、共有可能なコード資源、つまりライブラリの扱いです。Catyのコード資源は、schemata/, commands/ の2つのサブディレクトリに集約されています。共有可能なスキーマ／コマンドもありますが、一般的なライブラリ概念とはなんか違います。すべてのアプリケーションから使えるライブラリの置き場所はあるのですが、これは、アプリケーションの親子関係によるスコーピングには従いません（どこからでも可視）。
ライブラリファイルの置き場所として、アプリケーションごとに lib/ サブディレクトリを設けて、lib/ 内のコード資源の可視性も親子関係で制御される、としたかったのです（今、だいたいそうなっている）。
Catyはプロジェクト・スタート時点から公開状態で開発をしていますし（https://bitbucket.org/project_caty/dev/src）、拡張性も高いのですが、第三者がすぐに使えて、自分でモリモリ拡張できるかというと、ちょっと難しと思います。僕らが、そういうことにまったく労力をかけてないので、謎の処理系のままです。
労力をかけようにも、その余裕がないのでドーニモナラナイのが実情です。が、コア部分（3万行弱のPythonコード）はけっこう出来てきた*3し、実際に使ってもいるので、「第三者がすぐに使える」ための周辺部分をもうちょっとナントカシヨウと考えています。
「どこにどんなコードを追加したらどうなるか？」が単純で明確なルールで示せないと、いじりようがないですものね。いじらないで（なにも手を加えないで）そのまま使えるか？ というと、ある程度の複雑さを持つWebサイト／Webアプリケーションでは無理でしょう。コアだけでもけっこうな規模ですが、Catyコアは基本となるランタイムを提供するだけなので、特定の目的のためにはコマンドとライブラリを追加する必要があります。
コマンドとライブラリの追加を分かりやすく出来るように、commands/ に加えて lib/ を導入したわけです*4。
