Usually, for a MySQL storage engine, index cardinality stats (rec_per_key) are considered a part of "constant" table information, and so are updated on handler::info(HA_STATUS_CONST) call. However, TokuDB may return different rec_per_key values depending on the dynamic variable tokudb_cardinality_scale_percent value. The server does not have a way of knowing that changing this variable invalidates the previous rec_per_key values in any opened table shares, and so does not call info(HA_STATUS_CONST) again.
It seems more correct to update share rec_per_key on info(HA_STATUS_VARIABLE) calls too.
This is exposed by adapting https://bugs.launchpad.net/percona-server/+bug/1704195 for TokuDB