see also https://bugs.mysql.com/bug.php?id=87678

Also reproducible with MySQL 5.7.

In this script:

SET sql_mode=STRICT_ALL_TABLES;

DROP TABLE IF EXISTS t1;

CREATE TABLE t1 (a DECIMAL(3,2));

INSERT INTO t1 VALUES (1.234);

INSERT INTO t1 VALUES (10);

• the first INSERT query returns a warning
• the second INSERT query returns an error

Both should return an error.

This is not a bug, the behavior is intentional.

SQL Standard specifies that truncation is not an error. That's why we don't issue an error.
This is specified in SQL:2016, Part 2, Section 9.2 "Store assignment":

General Rules:
1) Let T be the TARGET and let V be the VALUE in an application of the General Rules of this Subclause.
...
3) Case:
    a) If V is the null value, then
    ...
    b) Otherwise,
        Case:
        ...
        xv) If the declared type of T is numeric, then
            Case:
            1) If V is a value of the declared type of T, then the value of T is set to V.
            2) If a value of the declared type of T can be obtained from V by rounding or truncation, then the value of T is set to that value. If the declared type of T is exact numeric, then it is implementation-defined whether the approximation is obtained by rounding or by truncation.
            3) Otherwise, an exception condition is raised: data exception — numeric value out of range.

Note that there is no exception when the value is truncated or rounded.

So implementing an optional non-standard behavior where this truncation causes an error is by all means a new feature.

Thank you for pointing out the SQL standard. That really helps.

However, this was never intended to be a bug.

It was also reported to Oracle as a feature request : https://bugs.mysql.com/bug.php?id=87678

Yes. I've changed it to a feature. Just wanted to point out that this feature will be non-standard and thus it must be optional (and, most probably disabled by default). But this feature kind of make sense, I agree. It might be useful in some cases, even if non-standard.