These option clashes happen when a package is requested to be loaded on two different positions, like by you and inside another package, but with different options. The package is loaded by the first \usepackage (or its twin \RequirePackage); it isn't loaded again when it is requested again. It simply can't be loaded a second time. Therefore the new options can be activated and previous options might conflict with the second usage. So LaTeX creates an error to report this issue to you.
The way to fix this is to declare the options beforehand using \PassOptionsToPackage{<options>}{<package>}. Then they are used wherever the package is loaded.
\documentclass{article}
\usepackage{ifpdf}
\ifpdf
\PassOptionsToPackage{pdftex,usenames,dvipsnames}{color}
\usepackage[T1]{fontenc}
\usepackage{libertine} % most likely loads 'color' itself
%\usepackage{lmodern} % doesn't load 'color'
\usepackage{color}
\usepackage[pdftex]{graphicx}
\else
%\bye
\fi
\begin{document}
Hello, world!
\end{document}
I can't test it by myself, because I don't have the libertine package installed.
PS:
I don't think you need to set pdftex manually. Normally packages do a good job recognizing the driver by themselves. Also you might want to use the extended xcolor package instead of color.
XeTeX introduced new primitives such as \Umathcode (up to version 0.9998 called \XeTeXmathcode, renamed for compatibility with LuaTeX) that's the Unicode analog of \mathcode.
What does \mathcode in traditional TeX? A declaration such as
\mathcode`+="202B
tells TeX that a + in math mode should be treated as a binary operation symbol (leftmost byte "2), taken from font family "0 and slot "2B in the corresponding font. In the same vein, one can say something like
\Umathcode`∑="1 "1 "2211
or even
\Umathcode`∑="1 "1 `∑
The primitive \Umathcode has the syntax
\Umathcode<Unicode point> = <math type> <family> <slot>
After the (optional) =, three numbers should be given, because packing the information into a single number as done by TeX is not possible. Actually the information is still packed into a single number (in this case it's decimal 18883089, hexadecimal "1202211), but the translation from packed number to explicit type-family-slot is not straightforward.
This will be probably accompanied by a similar declaration
\Umathchardef\sum="1 "1 "2211
so that typing $∑$ or $\sum$ will give the same result.
The unicode-math package loads a huge list of symbols and performs assignments similar to the one for ∑. The number corresponding to ∑ will be different, because it depends on many aspects which can't be covered in a short answer.
Actually unicode-math does much more than this, because it sets things up so that commands such as \mathbf or \mathrm give the desired result.
There are other primitives corresponding to the traditional ones, namely \Umathchar, for using a directly specified character, or \Udelimiter for setting delimiters with normal and large variant, \Umathaccent and finally \Uradical for defining root symbols. See texdoc xetex that will open “The XeTeX reference guide” by Will Robertson and Khaled Hosny.
Best Answer
You have several options
Don’t use
unicode-mathUnless you have a specific reason to use it, you don’t have to use it and your old code should work just fine.
Use a different math font
Some OpenType math fonts like XITS Math have both math calligraphic and math script alphabets. By default XITS Math has a math script alphabet and the math calligraphic alphabet is available through stylistic set 1. We can use
unicode-mathUse
\mathscrfrom a different fontThe default font, Latin Modern Math, has a math calligraphic alphabet only; we can use the math script from XITS Math. Though
unicode-mathloads Latin Modern Math by default, we have to explicitly use it for some reason or things will not be quite right.That being said, the root of this complication is because the people who encoded Unicode math symbol could not find any convincing evidence for the use in math of both the calligraphic alphabet and the math script in the same context to mean different things, so they considered it to be just a stylistic not semantic difference so they were unified in encoding.