The fact that multiple instances of bind can run on a single system (on different interfaces) with different configurations and the fact that mysql+threads+dlz can be build and used, but when using mysql, bind has be configured to spawn just 1 thread created a use case of removing constrain mysql? ( !threads ).
Instead of condensing the problem description into one tight little ball, you should expand it into multiple sentences and provide some steps to reproduce the problem.
*** Bug 701710 has been marked as a duplicate of this bug. ***
My bug report at https://bugs.gentoo.org/701710 has been marked as duplicate of this bug, but it seems the context has slightly changed during the last two years when this was originally reported. With "bind-9.14.8" (the lowest version currently in portage) I no longer see any "threads" use flag, but I can see that I indeed have USE="-threads" in my portage.use files, so it seems the removal of that flag from bind has actually triggered my problems in the first place. For reproduction and more details please check my original bug report. IMHO a warning during `pkg_postinst` could help a lot here, since in order to try to fix it I re-emerged bind multiple times ...
BTW. the bug reported here is basically solved/no longer present. It seems USE="-threads" was enforced in the past when USE="mysql" was detected. OP correctly points out that it might still be valid to build a multi-threaded bind even with mysql enabled, since it can be that you end up running multiple bind instances, where only one needs to be single-threaded (via CPU="1" or options="-n 1"). IMO the problem is now exactly the opposite, since it is no longer enforced and users might not be aware of this limitation. And for anyone who used `USE="-treads"` in the past will run into this pitfall again once they upgrade. After digging into all this, I more and more believe that a warning during post_inst and maybe additionally a comment in conf.d/named (maybe right beside the `rc_named_use="mysql"` part) seems to be the most sane solution to this problem.