Yes it’s expected.

A tuple cannot be changed. A tuple, like a list, is a structure that points to other objects. It doesn’t care about what those objects are. They could be strings, numbers, tuples, lists, or other objects.

So doing anything to one of the objects contained in the tuple, including appending to that object if it’s a list, isn’t relevant to the semantics of the tuple.

(Imagine if you wrote a class that had methods on it that cause its internal state to change. You wouldn’t expect it to be impossible to call those methods on an object based on where it’s stored).

Or another example:

>>> l1 = [1, 2, 3]
>>> l2 = [4, 5, 6]
>>> t = (l1, l2)
>>> l3 = [l1, l2]
>>> l3[1].append(7)

Two mutable lists referenced by a list and by a tuple. Should I be able to do the last line (answer: yes). If you think the answer’s no, why not? Should t change the semantics of l3 (answer: no).

If you want an immutable object of sequential structures, it should be tuples all the way down.

Why does it error?

This example uses the infix operator:

Many operations have an “in-place” version. The following functions
provide a more primitive access to in-place operators than the usual
syntax does; for example, the statement x += y is equivalent to x =
operator.iadd(x, y). Another way to put it is to say that z =
operator.iadd(x, y) is equivalent to the compound statement z = x; z
+= y.

https://docs.python.org/2/library/operator.html

So this:

l = [1, 2, 3]
tup = (l,)
tup[0] += (4,5,6)

is equivalent to this:

l = [1, 2, 3]
tup = (l,)
x = tup[0]
x = x.__iadd__([4, 5, 6]) # like extend, but returns x instead of None
tup[0] = x

The __iadd__ line succeeds, and modifies the first list. So the list has been changed. The __iadd__ call returns the mutated list.

The second line tries to assign the list back to the tuple, and this fails.

So, at the end of the program, the list has been extended but the second part of the += operation failed. For the specifics, see this question.