Respuesta: En las versiones de MySQL anteriores a la 5.0.3, cualquier número que no pareciese a primera vista un entero, se convertía a coma flotante antes de hacer ningún cálculo. Desde la 5.0.3, los números con decimales exactos (como "1.1" o "2.2") se tratan como números DECIMAL y se utiliza una nueva libreria de precisión matemática para realizar los cálculos matemáticos. Números como "1.1E0" no se consideran de decimales exactos, y los cálculos sobre dichos números se realizan utilizando rutinas de coma flotante. Los cálculos de coma flotante tienen por definición un número de errores de redondeo, por lo que 1.1+2.2 no es igual a 3.3 (sino a algo similar a 3.3000000715256) cuando este cáculo se realiza usando rutinas estandard de coma flotante. En casi todo el hardware fabricado desde 1980, la gestión de números con coma flotante se realiza según el estandard IEEE 754. Puedes obtener más información sobre esto en la Wikipedia, pero si tienes ocasión dale un vistazo al Apéndice B del libro Structured Computer Organization de Andrew Tannenbaum (sólo en inglés).

Respuesta 1: Hasta donde sé, tan sólo otras dos RDBMS soportan la sintaxis multiregistro en INSERT, IBMs DB2 y Postgres (Aportación de Björn Steinbrink).

Respuesta 2: Seguramente te sorprenda, pero esta sintaxis es de hecho un estandard SQL, de acuerdo al estandard SQL-99. Se trata de una de las pocas ocasiones en que MySQL se ajusta más a los estandards que otros productos RDBMS. Para más información sobre la sintaxis de MySQL INSERT, dale un ojo a esta página del manual MySQL. Cuando necesito saber algo sobre estandards SQL, yo suelo consultar el excelente libro "SQL-99 Complete, Really!", de Peter Gulutzan y Trudy Pelzer’s (que por desgracia parece agotado en todas partes).

Respuesta 1: REPLACE eliminará cualquier registro que provoque una violación de la PRIMARY KEY o UNIQUE KEY, antes de insertar los nuevos datos. Ya que el primer registro (1, 3) entra en conflicto con la PRIMARY KEY (1,1), ese registro es borrado y (1,3) se insertará en su lugar.

Respuesta 2: Ahora tenemos dos conflictos: El primer registro (1,2) provoca una violación de la PRIMARY KEY y el segundo registro provoca una violación de la clave UNIQUE. Asi que ambos deben ser borrados para "hacer sitio" al nuevo registro.

Respuesta 3: El primer REPLACE afecta a dos registros (uno eliminado, uno añadido). El segundo replace afecta por su parte a tres registros (dos eliminados, uno añadido). Más información sobre la sintaxis de REPLACE disponible aqui.

Podemos omitir el ORDER BY. En MySQL, cuando usamos GROUP BY, los registros se ordenan de forma automática según los valores de las columnas indicadas en el GROUP BY, como si tuviésemos un ORDER BY en esas mismas columnas. De hecho, debemos indicar ORDER BY NULL si queremos evitar este comportamiento por defecto. Además, podemos indicar directamente ASC o DESC sobre el GROUP BY para hacer que la ordenación siga dichos parámetros. Más información aqui.