sandbox has the potential to cause problems with some software. It would be helpful to give some way for ebuilds to opt-out of being sandboxed when they are know to trigger bugs/flaws in sys-apps/sandbox. Lack of such a mechanism has led to the development of a sandbox escape tool (app-portage/unsandbox). It seems like it would be much simpler to offer some global variable to disable sandbox in the first place.
I'm thinking that a new RESTRICT value might be logical. This would allow sandbox to be disabled in response to USE conditionals as well.
While I was looking for such a functionality more than once I am actually not sure if this would be a good idea: Keep in mind that people may expect something when they set FEATURES="sandbox" or FEATURES="usersandbox". A possibility to allow ebuild maintainer to disable sandbox would clash with user choice and may have undesired impact. So I think we should only warn in case of known problems like currently happening in dev-db/{mysql,mariadb,percona-server} or sys-apps/coreutils but still allowing users to emerge these packages with sandbox. And in case of a serious issue like infinite running test suite like seen in bug 624012 for sys-block/mbuffer src_test should be skipped or package should fail in first phases like pkg_pretend (but not when doing binary merge in most cases!) if there's a general problem with sandbox and sandbox is activated.