MySQLとMariaDBは相前後して生成列（Generated Column）の対応を行いました。
現在の対応状況を試してみました。
MySQL 5.7.12
生成列名 データ型 as ( 関数または計算式 ) [ virtual | stored ]
デフォルトはvirtualで省略できる。
virtualで生成した列（仮想列）に対してもINDEXの作成が可能。
制限事項
仮想インデックスの場合は以下の制限あり
１．主キーはいかなる仮想列も包含できない
２．仮想列と非仮想列の混在に対してはインデックスが生成できない
３．仮想列に空間あるいはフルテキストインデックスは生成できない
(この制限事項は今後解消される)
４．仮想インデックスは外部キーとして利用できない
MariaDB 10.2
生成列名 データ型 as ( 関数または計算式 ) [ virtual | stored | persistent ]
storedとpersistentの違いがよく分からない。たぶん同じ？
・仮想列(virtual）についてはindexを作成できない。
・現バージョン（10.2）だと原因は分からないがdate_format関数がエラーになる。文字列にcastしてsubstrをconcatすれば回避は可能。
MySQLの仮想列indexは記憶領域としては索引部分しか必要としない。ある意味関数indexに近い。
ただ、
select * from
とした場合はindexではなくその都度計算を行う模様。
生成列は仮想列でも実データ格納（stored)でもテーブル項目の一部（ただし、更新不可）なので
insert into テーブル名 values ( ... )
とは記述できない。生成列の除く項目リストをテーブル名の後に明示的に記述する必要がある。
insert into テーブル名 (col1,col2,col3,...) values ( ... )
これはMySQLでもMariaDBでも変わらず。
ここのあたりを面倒と考えるか、関数indexとして使え検索負荷の軽減を重視するか（一方で更新負荷も発生するが）というあたりのバランスをどう見るかというあたりかな。
余談
MySQLは次期バージョン8.0で再帰問合せ（共通表式）に対応するとのこと。（再帰を伴わない共通表式には5.6で対応）
MariaDBは10.2で再帰問合せに対応済み。ウインドウ関数にも対応している。一方で仮想列にindex作成できないという弱みもある。
MySQLがウインドウ関数対応を行うかは注目に値する。
以前のオラクル社の姿勢は「WEB向けRDBとして存在価値はある」ということだったと記憶しているが。
あと、ハッシュ結合に対応するかも興味深い。商用向けとは言えMySQL Clusterの位置づけなどをどうするかも含めオラクルとしても判断が難しいところだろう。
MariaDBは競合DBを抱えているわけではないのでその点では自由だ。MariaDBがフォークして、互いに差異をどう作るか問われる状況になってきた印象。