なんでまたInput Methodが変わるようなことになっているんだ、一体何が起きているんだ、というのは、まぁ当然出てくる感想ではなかろうかと思います。
とはいえ、UbuntuでSCIMが使えるようになったのは6.06からで（その前にあったのは私の非公式パッケージ）、SCIMからIBusに変わったのが9.10からなので、Ubuntuの歴史9年間を考えるとそんなにコロコロ、ってわけでもないと思います。いや、どうなんでしょう。自信なくなってきました（ぉぃ
もうちょっと大きな流れで見てみると、
kinput2→SCIM→IBus(→Fcitx?)という変遷かと思います。Fedoraは確かKinput2→IIIMF→SCIM→IBusという流れですね。
よくよく考えてみると、これってその時々のニーズに応じた変更になっていることがわかるのです。
それを記憶ベースで書き出してみます。あくまで記憶なので間違ってたらごめんなさい。
Kinput2→SCIMはどんなメリットがあったのかというと、まずは1つのInput Methodで複数の変換エンジンを瞬時に変更できましたし、そればかりか言語をまたいだ変更も可能でした。GTK+（とQt）にImmoduleという仕組みが導入され、1つのInput Methodで複数（って2つしかないけど）のImmoduleをサポートする必要もありました。当時の時点で多言語化に優れていたのがSCIMで、これが選択されたと記憶しています。
SCIMは確かに優れていましたが、SCIMと変換エンジンを繋ぐIMEngineを書くのにC++が必要だったこと、C++で書かれていたからlibstdc++のバージョンに依存していたこと（のちにscim-bridgeで解決）、SCIMが落ちたらアプリまで落ちちゃうなど、いろいろな問題がありました。作者さんもTurbolinux→Novell→Googleと転職してアクティビティが下がったというのも原因の一つかもしれません。
IIIMFの作者とSCIMの作者で新しくimbusというのを作ろうとしたものの、コミュニケーション不足やらそもそも構想が壮大すぎるやらでさっぱり進まなかったので、その構想を手っ取り早く実装したのがIBusと、私は理解しています。設定ツールやらIMEngineやらいろいろなものを独立したプロセスにして、プロセス間通信を使用するとか、そのあたりです。あとは全体をPythonで書いてC++の知識がなくてもIMEngineを書けるようにしたとか、SCIMから着実に改良しています。もっとも、パフォーマンスの問題でコアはC言語で書きなおされましたが。IBusの作者さんも、元はRed HatでしたがGoogleに転職しています。
IIIMFは少なくともLinuxディストリビューションでは主流になることはありませんでしたけど、Solarisではよく使われましたし、ATOKでも使用していました（います、ですね。現在進行形です）。あ、SolarisでもATOK使えるし同じじゃん。
これが主流にならなかったのは、たぶん大きすぎ複雑すぎたのが原因じゃなかろうかと思います。セキュリティの問題もありましたけど、のちに修正されています。まぁそれが遅すぎたというのはあると思いますけど。あとはパッケージャー泣かせでもありました。
uimは確かに主流にはならなかったですけど、息は長いですし、Debianではデフォルトですし、筋が良かったのは間違いありません。そもそもメンテナーが何人も(5人？)交代して10年以上継続しているInput Methodってこれしかないわけです。これはすごいことです。主流になれなかったのは中国語対応が弱かったからでしょうか。SCIMもIBusもFcitxも作者は中国人ですね。
Fcitxに関しては、どう評価すればいいのかよくわからない、というのが本音です。というのも、私が中国語を知らないのでIBusと比較してどういうメリットがあるのかわからないのです。
Input Methodとしては、IBusよりもSCIMに近いというか、IBusとSCIMの中間というか、若干戻った感じもします。IMEngine（という言い方をするのかは知りませんが）はC++ですし。
とにかく細かな設定ができるのがFcitxの特徴だと思います。ただ、最初にそれを見たときはあまりに設定項目が多すぎて困ったし、実際自分で使う気にはなりませんでした。twitterでつぶやいたら作者さんもそうだよね、でも最新版ではまた変わってるから試してみてって言われたので、実際試してみたらわりといい感じだと思いました。今は当時よりもさらに項目が減っていますが（減っているというか隠してあるだけですけど）、このぐらいならいいと思います。
Fcitxが注目されたのは、やはりIBus 1.5の失策によるものという感は否めません。IBusも最初GNOMEと統合すると聞いたときはいい事だと思ったのですが、あんなに機能を削られるとは思いませんでした。シンプルというのと機能を削るのはイコールではない気がします。LinusもGNOMEに関して似たようなことで怒っていましたよね。それでもGNOMEは概ね正しい方向で進化しているとは思いますけど、なんであんなにフォークされまくるんでしょうか。
なんだかうざい昔語りになってしまいましたが、Input Methodの変更にはそれなりのメリットがあったのだよ、というお話でした。
とはいえ、UbuntuでSCIMが使えるようになったのは6.06からで（その前にあったのは私の非公式パッケージ）、SCIMからIBusに変わったのが9.10からなので、Ubuntuの歴史9年間を考えるとそんなにコロコロ、ってわけでもないと思います。いや、どうなんでしょう。自信なくなってきました（ぉぃ
もうちょっと大きな流れで見てみると、
kinput2→SCIM→IBus(→Fcitx?)という変遷かと思います。Fedoraは確かKinput2→IIIMF→SCIM→IBusという流れですね。
よくよく考えてみると、これってその時々のニーズに応じた変更になっていることがわかるのです。
それを記憶ベースで書き出してみます。あくまで記憶なので間違ってたらごめんなさい。
Kinput2→SCIMはどんなメリットがあったのかというと、まずは1つのInput Methodで複数の変換エンジンを瞬時に変更できましたし、そればかりか言語をまたいだ変更も可能でした。GTK+（とQt）にImmoduleという仕組みが導入され、1つのInput Methodで複数（って2つしかないけど）のImmoduleをサポートする必要もありました。当時の時点で多言語化に優れていたのがSCIMで、これが選択されたと記憶しています。
SCIMは確かに優れていましたが、SCIMと変換エンジンを繋ぐIMEngineを書くのにC++が必要だったこと、C++で書かれていたからlibstdc++のバージョンに依存していたこと（のちにscim-bridgeで解決）、SCIMが落ちたらアプリまで落ちちゃうなど、いろいろな問題がありました。作者さんもTurbolinux→Novell→Googleと転職してアクティビティが下がったというのも原因の一つかもしれません。
IIIMFの作者とSCIMの作者で新しくimbusというのを作ろうとしたものの、コミュニケーション不足やらそもそも構想が壮大すぎるやらでさっぱり進まなかったので、その構想を手っ取り早く実装したのがIBusと、私は理解しています。設定ツールやらIMEngineやらいろいろなものを独立したプロセスにして、プロセス間通信を使用するとか、そのあたりです。あとは全体をPythonで書いてC++の知識がなくてもIMEngineを書けるようにしたとか、SCIMから着実に改良しています。もっとも、パフォーマンスの問題でコアはC言語で書きなおされましたが。IBusの作者さんも、元はRed HatでしたがGoogleに転職しています。
IIIMFは少なくともLinuxディストリビューションでは主流になることはありませんでしたけど、Solarisではよく使われましたし、ATOKでも使用していました（います、ですね。現在進行形です）。あ、SolarisでもATOK使えるし同じじゃん。
これが主流にならなかったのは、たぶん大きすぎ複雑すぎたのが原因じゃなかろうかと思います。セキュリティの問題もありましたけど、のちに修正されています。まぁそれが遅すぎたというのはあると思いますけど。あとはパッケージャー泣かせでもありました。
uimは確かに主流にはならなかったですけど、息は長いですし、Debianではデフォルトですし、筋が良かったのは間違いありません。そもそもメンテナーが何人も(5人？)交代して10年以上継続しているInput Methodってこれしかないわけです。これはすごいことです。主流になれなかったのは中国語対応が弱かったからでしょうか。SCIMもIBusもFcitxも作者は中国人ですね。
Fcitxに関しては、どう評価すればいいのかよくわからない、というのが本音です。というのも、私が中国語を知らないのでIBusと比較してどういうメリットがあるのかわからないのです。
Input Methodとしては、IBusよりもSCIMに近いというか、IBusとSCIMの中間というか、若干戻った感じもします。IMEngine（という言い方をするのかは知りませんが）はC++ですし。
とにかく細かな設定ができるのがFcitxの特徴だと思います。ただ、最初にそれを見たときはあまりに設定項目が多すぎて困ったし、実際自分で使う気にはなりませんでした。twitterでつぶやいたら作者さんもそうだよね、でも最新版ではまた変わってるから試してみてって言われたので、実際試してみたらわりといい感じだと思いました。今は当時よりもさらに項目が減っていますが（減っているというか隠してあるだけですけど）、このぐらいならいいと思います。
Fcitxが注目されたのは、やはりIBus 1.5の失策によるものという感は否めません。IBusも最初GNOMEと統合すると聞いたときはいい事だと思ったのですが、あんなに機能を削られるとは思いませんでした。シンプルというのと機能を削るのはイコールではない気がします。LinusもGNOMEに関して似たようなことで怒っていましたよね。それでもGNOMEは概ね正しい方向で進化しているとは思いますけど、なんであんなにフォークされまくるんでしょうか。
なんだかうざい昔語りになってしまいましたが、Input Methodの変更にはそれなりのメリットがあったのだよ、というお話でした。
トータル
https://fcitx-im.org/wiki/History
So it's 11 years still now.
As for ibus 1.5, there is a story like this: they drop some function, and add it back only for gnome (due to they integrate with gnome, they move the function into gnome-shell), and thus only under gnome it's available, so for other desktop it still...
しかしGNU/Linux上の入力環境ってコロコロ変わるだけでちっとも進化してないなあ… ちなみにモバイルOSのTizenはAndroidとは異なりX11を使っているんですが、インプットメソッドについては上記とも異なる独自のフレームワークを持ってるようです（サムスンが主導しているんでEFLを使用）。
この書き込みがなされた 2013 年頃は、NetBSD で FVWM で kterm && kinput2 && canna でした。
今(2023)は Debian で MATE で uim で mozc です。
よる年波には勝てません。