Can insert on tables with FK impact operations on other tables that have FKs to the same table?
My attitudes in this area:


Make transactions so fast that there are rarely any conflicts.
Use SELECT ... FOR UPDATE to "lock" rows that I am about to update.  (Unless there is a way to avoid them.)
FKs imply extra checks.  These take time.  And the checks are usually redundant.
I don't use FK CASCADE since I like to see all the interactions in the same code -- namely the code between BEGIN and COMMIT.
I don't use non-cascading FKs; I debug my code instead.
I do use INDEXes and I want to know exactly what indexes exist and not be surprised by extra (redundant?) ones created by FKs.
Do check for errors after every SQL statement.  These can be surprise deadlocks.
Check for errors even after COMMIT.  This is in case the app is ever migrated to Galera or InnoDB Cluster.
Restart at the BEGIN if there is a deadlock.
Beware of "burned" AUTO_INCREMENT ids.  (That's a lengthy discussion of its own.)


Back to your question.

There are cases where InnoDB takes a stronger (eg, X vs S) lock than it needs to.  This may be because of an edge case that is too costly to check for.  Your example may (or may not) be an example of such -- I don't have enough brain cells think it through at the moment.  I go back to my first bullet item -- make the transaction fast enough so the problem goes away.