Turing Machines proof notations
$\langle x \rangle$ simply denotes the encoding of some object $x$. $x$ can be a TM (e.g., its Gödel number), a string, some combination thereof (properly separated), or even other objects like a graph, etc.

This serves, for instance, to distinguish between $\{ \langle M \rangle \mid \text{$M$ is a TM} \}$, which contains encodings of TMs (e.g., their Gödel numbers or representations in binary), and $\{ M \mid \text{$M$ is a TM} \}$, which is the set of Turing machines themselves (as mathematical objects). The underlying motivation is that it is not clear how a TM (as an object) can be passed as an input; what you do is provide its "program", that is, its states and transition function.

When multiple objects are encoded together as a single string (i.e., to be seen as a single object), it is usual practice to denote it as $\langle x_1, \ldots, x_m \rangle$. Again, it is not immediate what the encoding is. It could be simply concatenating the encodings of each $x_i$ and separating them (e.g., $\langle x_1, \ldots, x_m \rangle = \langle x_1 \rangle \# \cdots \# \langle x_m \rangle$); it could also be that the encoding of $x_i$ is altered in some way (e.g., each $0$ or $1$ in $\langle x_i \rangle$ is doubled and each such representation is separated by $01$); it could even be that the entirety of the representation is compressed (so as to reduce its length) or that it is subject to some predetermined enumeration (e.g., as a vector over some countable space).

Generally, if they are relevant to the context at all, these descriptions should be made precise beforehand, as most textbooks do. In computability theory, except when covering Gödelization, they usually are not; this is because the actual length of the input is irrelevant to computability questions. Things are different in complexity theory—though it usually does not get much attention there either (besides coming up in a preface or similar); most objects are encoded in binary anyway, and multiple objects with only a constant stretch, which suffices for almost all complexity-theoretical topics.