Shouldn't C:7 be in P3's write set, and therefore get into a conflict with P1's T1 commit?

It's in the next slide.

C:7 will be in P3's write set; yet it doesn't conflict with P1's T1 commit -> when P3 writes C:7, P1's T1 has comitted.

I understand in this instance why T3 isn't said to conflict with T1 here because ultimately the write will happen and overwrite it whether we call it a conflict or not. However, in slide 11 of lecture 14 in the optimistic detection examples, a similar situation in Case 4 meant that we did restart the transaction. What is the difference between these two cases?

When T2 commits, its write set has E. T4's read set also has E which is why T4 restarts when T2 commits. But when T1 commits though its write set and T3's write sets have C, T3 does not restart because this is lazy data versioning. Its as simple as P2 writing to a memory address after P1 does.

I think there may be a typo on this slide. For transaction 4, it says read f but f is never added to the read set.

oh nevermind! I just lost my place for a second:)