Someone on the CTC discord came up with the following argument (sort of the reverse of my r1c1 case above):
Set box 5 (1r4c4, 2r5c6, 3r6c5, WLOG). Both of r3c4 and r4c3 see r4c4, so they are both 2 or 3.
Case 1: r3c4 and r4c3 are the same (say 2, WLOG). Then r2c5 and r6c1 are both 1 due to 3r6c5, r1c6 and r5c2 are both 3, and now r1c1 and r2c2 must both be 2.
Case 2: r3c4 and r4c3 are different (say 23 in that order, WLOG). Now 1 must be in r2c5 and r5c2, putting 2 in r6c1 and 3 in r1c6... and now r1c1 and r3c3 must both be 1.
These puzzles weren't specifically designed with this pattern (or any pattern) in mind. They are result of neighborhood searches on existing hard puzzles. I have four scripts that I run:
"Generator" (-2, +2), "Adder" (-1, +2), and "Reducer" (-2, +1) all generate new potential grids by removing 1 or 2 clues and then adding back 1 or 2 clues, in all possible ways. If the result is uniquely solvable, distinct from other puzzles in the database, and sufficiently hard to pass some filters (I use backdoor count and q2 as a first pass filter, then skfr as a second filter; I also calculate q1 if it passes both filters), then they get added to the database (trying to find the right balance between having it in the database so I don't rate it again in future, and not having the database too big).
"Expander" takes a puzzle, adds all possible singles, and then minimizes the result; there's no filter on these, the resulting puzzles are guaranteed to be at least as hard (unless there is a uniqueness pattern being used, perhaps) so I just calculate the new ratings if it's a new puzzle. The main benefit to this one has been in improving the seeding of the larger clue count databases.
I have a complicated (and somewhat arbitrary) metric for choosing puzzles to try next, and I run these on a variety of clue counts to reduce the chance of a database collision (until I convert this into a proper multi-threaded program). And then I have a separate database for sufficiently hard filter ratings to be rated with SER, which is eating most of the CPU threads all the time.