Hi all! This is my first post here.

I have recently started to explore the historical bitcoin transactions for analysis. I'm following on the work of applying clustering to map different kind of users based on their transaction behaviors. I'm still on a early-exploratory stage of the analysis and I have found some transaction chains with a behavior that looks confusing to me. I tried to use the search here to found someone talking about this before but found nothing.

If you look at this transaction set from 2011 (Just a small sample):

(a) 71ae7f0ee983b257bd8ef0fecf11be3e3c5aa610988a286bec12fa98d1ef726f
(b) 067807fe9ce6cf33e0fab8912e5a6a15e4e990df50e92a20f0ab898386ed94f6
(c) 5c9ac4770895f00e0c6988689a1a5c5a6ae9b6a182dbce8ca46f3854b8523750
(d) e46e1463321d6adbf65a877634a75ff3cc519905e5670fb8f2a175a402e91350
(e) b76fefcbb5f637b62607091d579ce66c2078a7be627d46f54984a13d16aa3168

It looks like

...->(a)->(b)->(c)->(d)->(e)-> ...

You'll notice that each one of this transactions spends the change from the previous transaction. I think is the normal behavior.  I might suspect this chain of transactions was included by the miner in a low-demand point in time.

What I seem a little bit odd is that all of this very long chain of transactions is included on the same block 72624.

And you can easily infer this from looking at the whole block:
000000000024e041a4600f8ac4a55047457b2c2bc55d1993d755fe60cb5bfc04

I understand that each message is broadcasted independently so this could be a miner splitting his earnings into several addresses (You can see that many of them still unspent). However it's interesting that they can broadcast this chain of transactions and get included on the same block. I was looking at the code of bitcoind and apparently the existence of previous transactions is checked before considering a TX valid.

https://github.com/bitcoin/bitcoin/blob/master/src/consensus/tx_check.cpp

My question then would be: The consensus algorithm also checks against unconfirmed transactions in the mempool?

How this behaviour is handled today and in high-traffic situations? I.E:

I prepare a transaction (T1) (a)->(b) where (a) is an unspent output already verified in a previous block.
But I also prepare another transaction (T2) (b)->(c) that obviously depends on (T1) that is not confirmed yet.

What happens if I broadcast both transactions at the same time and I specify a really high fee for T2 so it can get a higher priority than T1. It's rejected?

I can imagine in 2011 doing this kind of things with low traffic could work, but today I don't know how the consensus algorithm would handle this kind of cases.

Thanks in advance for all the help! If it's a a newbie question please help me to figure where I can find more detailed information for similar cases here in the forum. If this is a common behavior of some specific implementation of bitcoin I would be happy to learn about it.