バージョン間の違いなど細かいことまではわかりませんが、モジュール内でとりあえず
import sys
しておけば大丈夫なようです。

スクリプトエディタから実行するときは内部で自動的にimport sysしているので記載はいらないのですが、分離されたモジュールではそれぞれimportが必要ということではないでしょうか？
Pythonの組み込みやモジュールに精通しているわけではないので答えとして正確かどうかはわかりませんが。

>バージョン間の違いなど細かいことまではわかりませんが、モジュール内でとりあえず
>import sys
>しておけば大丈夫なようです。

すみません、サンプルが悪かったです。
僕のpyファイルはちょっと長いので載せませんが、Metasequoia4.5まで動いていたpyモジュールが、Metasequoia4.6では以下のようなエラーが出ます。

Failed to execute a script in line 1, 'test.py'.
Module not found.
No module named 'version'

パスが通っているか
print(sys.path)
で確認してみてください。

既存のファイルを開いたか名前をつけて保存した状態なら、標準ライブラリ用のフォルダの他に、そのpyファイルがあるフォルダもパスに含まれていると思います。

>パスが通っているか
>print(sys.path)
>で確認してみてください。

Metasequoia4.6.1起動後に最初に実行したモジュールのパスしかありません。
2つ目以降のスクリプトのモジュールのパスを反映するにはどうすればいいでしょうか？

>2つ目以降のスクリプトのモジュールのパスを反映するにはどうすればいいでしょうか？

パス自体を変更する方法は用意していませんが、
・pyファイルと同じフォルダ
・標準ライブラリのあるPython\Libフォルダ
のどちらかにモジュールを置けば大丈夫だと思います。
（後者だとPrograms Files以外の書き込み可能なフォルダに本体をインストールしておくほうがいいかもしれません）

他のコマンドに切り替えるとボーンは必ず非表示になるので、今のところ方法はないということになります。
平面的なボーンであれば、スクリーンキャプチャして下絵として表示する方法なら一応できなくもないというくらいでしょうか。

4.6.0からOpenGL表示時にGLSLを使うようになったのでその影響だと思いますが、ブラックアウトは起こそうと思って簡単に起きるものでもないので、断定はできませんが例えば
・GPUのドライバの品質が低い
・GPUの電力供給が不十分
・GPUの放熱対策が不十分
・GPUが物理的に故障している
といったハードウェアやドライバ側の問題の可能性が高いと思います。

>といったハードウェアやドライバ側の問題の可能性が高いと思います。
現象が発生した時間のイベントログを漁ると
>ディスプレイ ドライバー igfx が応答を停止しましたが、正常に回復しました。
というイベントが記録されていたのでintelプロセッサの内臓GPUのドライバに起因するみたいですね。
GPUのドライバー更新は都合の悪いところもあるので、描画の品質を妥協して安定性を追求した描画モードを搭載してもらえないでしょうか。

>GPUのドライバー更新は都合の悪いところもあるので、描画の品質を妥協して安定性を追求した描画モードを搭載してもらえないでしょうか。

品質に問題のあるものの上で安定して動作させるというのは、物理的に不可能なことです。
そのためにDirect3D 9/11/OpenGLの3モードも用意しているので、必ずどれかは安定して動くはずですが、もしどれもだめならほぼドライバの問題かハードウェアの故障が原因と言って間違いありませんので、ソフトウェア側では対処のしようがありません。
新しいドライバーがあるならそれを入れるべきですし、既に最新なら修理や買い替えをお奨めします。

今回の問題点は、4.5.9までOpenGLを使用していたのに、4.6.0になってGLSLを採用し逆に不安定になってるのが問題だと思います。

それ以前で安定動作していたのが、GLSL採用によるソフトウェアがバージョンアップして不安定になったのをハードウェアの故障、ドライバの問題というのはちょっと乱暴じゃないでしょうか？

何か理由があってGLSLを採用したのだと思いますが、まずその点を説明すべきかと思います。
実際問題、GLSLを採用した故にハードウェアによる影響が大きくなりこれまで起きていなかった問題があるのであれば、それはGLSL採用した上での問題点としてソフトウェア側で何か対策すべきだと思います。
（旧式の表示方法を残すなど）

4.5.9までOpenGLを使用していたのに＞4.5.9までOpenGLを安定して使用していたのに

>何か理由があってGLSLを採用したのだと思いますが、まずその点を説明すべきかと思います。

そもそもなぜOpenGLを利用しているのでしょうか？
Windows版でOpenGLを使うメリットは元々なく、Direct3D 9/11の使用を推奨していますが、どうしてもDirect3Dが不安定な場合にのみOpenGLも選べるようにしております。これがもし全部だめならハードウェアやドライバの問題を疑うのは当然ではないでしょうか。

GLSLの採用理由はMacとの共通化によるもので、旧来のOpenGLと共存が難しいため基本として廃止しております。何もかも残していくことは現実問題としてできません。新しいものを取りいれるためにはレガシーを切り捨てる必要があることご理解ください。

>そもそもなぜOpenGLを利用しているのでしょうか？
mqouserさんの方はわかりませんが、私の方ではDirectXが怪しいときに一時的にOpenGLを選択して凌いだりしてますね。
その際に、GLSLで不安定になられているとちょっと困るかなと思います。

GLSL採用の理由がMacとの共通化とのことですが、開発コスト的に、両方のサポートは難しいというのはあるでしょうが、WindowsユーザーはあくまでWindows環境で動作するメタセコのためにライセンスを購入してると思いますので、Macと共通化するためにGLSL採用で問題がおきてる環境があるというのはなんだかなと感じます。

Macと共通化された結果、WindowsでもOpenGL表示が大幅に高速化され、Matcap表示も可能になるなど機能・性能面で大きく向上しています。
Direct3D 11が使える限りは依然としてOpenGLは必要ではありませんが、やむを得ずOpenGL表示を使う場合にもメリットがあるわけで、省力化のためだけに共通化したわけではありません。

GLSLも新しいバージョンではなく10年近く前からある基本的な機能しか使っていません。GLSLが原因かもとは言いましたが、他にも変更箇所は多いのでGLSL採用が原因とも限らず、元々不安定だったのが顕在化しただけの可能性もあります。
いずれにせよアプリ側からディスプレイドライバを停止させるのは容易にできることではなく、ドライバまたはハードウェア側に何らかの問題があるのはほぼ間違いないと思います。

私自身の最近の経験でもOSをアップデートしたら急に動作が不安定になったことがありましたが、本当の原因はメモリが物理的に壊れていたためで、この場合の唯一の解決法は新しいメモリを買って交換することでした。
特定の環境でのみ起こる問題をソフト側でなんとかするというのは正直いって難しいのです。余ってる古いビデオカードかノートPC差し上げるくらいしかできません。

ご返答ありがとうございます。
頂いた内容からGLSLのメリット、経験によるハードの問題じゃないかという推測は分かりましたがそのあたりを最初に説明すべきだったのではないかと思います。

Ver4.5.9以前は問題なかったのに、4.6.0からいきなり起きている現象のようですし、それでいきなりハードが悪い、修理買い替えろは乱暴だろうと感じました。

ビデオカード、ノートPCを差し上げる話は誰もされても困ると思うので…、なるべく出来る限りブラックアウトしない対策を可能なら行ってほしいところです。