Fk are good when you use natural pk,
but this is unlikly in thie project, every table use an ai pk field --> unnatural pk.
So ther is no update to change this pk.
Other thing is data quality,
that you can only insert id in detail table which exists in the main table,
but the question why should you try to insert a wrong fk_id?
The problem when you got a complex fk table construct you need to watch out to fill the table in right order (which can be hard!),
so in good database (not mysql) you can change the fk to be defferend https://www.postgresql.org/docs/9.6/static/sql-set-constraints.html
so that they checked after the transaction is commited.
In mysql your are lost, you can disable fk checks SET FOREIGN_KEY_CHECKS=0; -- SET FOREIGN_KEY_CHECKS=1;
but than is no check if the data are correct.
the cascading delete is in most case not wanted,
example someone harm you board but this is year ago.
When his account is delete you only got his id or even the log entry is deletet so you got nothing from this user.
Another important note smf 2.1 is not only support mysql, the postgresql support is heavy extended so
in the best case what ever you do should work in both.