You should not mix TeX binaries of different TeX distributions. If you like to use pdflatex of MiKTeX, install a minimal MiKTeX. To avoid doubling of all packages you can install the TEXMF tree of TeX Live (usually texlive/<year>/texmf-dist) as an additional TEXMF root with MiKTeX settings.
As an alternative you could fake the -include-directory option using a batch, that extends TEXINPUTS variable before calling TeX Live's pdflatex.
This is a complement to egreg's answer
The source of the problem is that etoolbox hence etex will be loaded at a time where < is active. This is not completely catastrophic though, because even with < active, it might well expand to a catcode 12 < hence could work ok in \ifnum tests. However when package color is loaded and used with driver pdftex it then loads support file supp-pdf.mkii for MPS to PDF conversion. This file temporarily modifies the definition of \protect. And the active < then gives something unacceptable to \ifnum.
With only \usepackage[italian,spanish]{babel} and without color there is thus no error.
For some reason spanish.ldf temporarily makes makes < and > active during the time it is loaded by babel at the very end of spanish.ldf. This activity is cancelled for the rest of the preamble until \AtBeginDocument by code executed immediately after babel.sty is loaded. In the order \usepackage[spanish, italian]{babel} the loading of etoolbox which was demanded by italian.ldf at the end of package Babel is thus executed after the code, also at end of package Babel, which resets to unactive the catcodes of the activated characters by spanish (edit: activated at the very end of spanish.ldf itself).
In the order of \usepackage[italian,spanish]{babel} the end of package Babel demands of italian (which include the loading of package etoolbox hence also of package etex) are executed before those of spanish. As a result this is done at a time where < is active. Hence etex definition of \alloc@ is done with an active <. This is recipe for disaster although as seen above in some circumstances it may remain hidden, becasue the active < still will extend to a catcode 12 <.
I do not know enough the innards of Babel, but it appears to me that spanish.ldf should not demand to Babel to reset the catcodes of < and > at the end of loading of babel.sty [snip] but do it him/herself at the end of spanish.ldf...
in fact I am not sure spanish.ldf makes any explicit demand of this type what I see is that
- it demands to Babel to activate
< and >,
- then it immediately resets the catcodes to
12,
- then at the very last command of
spanish.ldf one sees it re-activates < and >.
Babel by default I think resets to 12 the catcodes for the rest of the preamble when the activation was done properly (I do not investigate more, but I tested it in the case of spanish by itself).
Thus, I recommend this issue should be raised to the spanish.ldf and babel.sty maintainers. In fact, it would seem that the \csname activatequoting\endcsname at the end of spanish.ldf might be a bug (perhaps should be from what I understand only \let\es@quoting\activatequoting but not do \shorthandon{<>} ?), as anyhow Babel resets for the rest of the preamble the catcodes to 12.
Best Answer
There has been apparently an unapproved or experimental MiKTeX2.9 x64 for Windows available which somehow was downloaded on my machine as the update required for MiKTeX approximately around the 3rd of October 2015. This experimental update includes several files among which several are of the form MiKTeX209-next-*.dll. This experimental update is not good and breaks the pdflatex engine (among others). The best remedy is to uninstall completely the MiKTeX installation using the MiKTeX uninstall program in Control Panel.