Do you have anything in your env that would export 'INCLUDE' var ?
It's most likely either in your shell config files or in /etc/env.d.

Commenting the line
source /opt/intel/composerxe/bin/compilervars.sh intel64
out from my /etc/profile solves the problem. However, I still think that there is something wrong with this ebuild particularly. I've always used this source in my /etc/profile and never had any similar problem. It seems like libtool is forgeting something specifically for this ebuild._________________"Nolite arbitrari quia venerim mittere pacem in terram non veni pacem mittere sed gladium" (Yeshua Ha Mashiach)
Who will save us from pulseaudio and systemd?

It's not related to the ebuild - the package itself uses the var.
But TBH it's silly both sides - yours and the package.
Package assumes that a var with a generic name won't be used by any other package, you assume that a var with a generic name is safe to be exported into common env.

It's not related to the ebuild - the package itself uses the var.
But TBH it's silly both sides - yours and the package.
Package assumes that a var with a generic name won't be used by any other package, you assume that a var with a generic name is safe to be exported into common env.

I need the var to be exported within the common env because I am EXPECTING everybody to use Intel's MKL. I don't see what is silly about using Intel MKL.

The package is using libtool for configuring things. As I mentioned before, it looks to me like litool is not putting a given -I there. I would like to know if anyone has any idea on why it is happening._________________"Nolite arbitrari quia venerim mittere pacem in terram non veni pacem mittere sed gladium" (Yeshua Ha Mashiach)
Who will save us from pulseaudio and systemd?

1. libtool is doing sh*t here - see configure.in of sdl-mixer (likely something as simple as 'echo $INCLUDE' will show this)
2. the point is that 'INCLUDE' is a very generic name, so there's no telling if a random package won't decide to use it for one purpose or another; my very first question was about your make.conf, cause this is in a way a variation of many RESOLVED/INVALID bugs for libvpx, where the build system is even more volatile to vars with generic names (like i.e. 'CODECS')