brut-ish force...

If performance is a concern, it's still better to write the 'yield' expression. These are lazy gens and they're sometimes half as slow, but it's likely just splitting hairs unless you're working on exceptionally large sets of data.

Actually, generally accepted best practice is to not use named lambdas. Lambdas should be 'throw away' expressions, not statements and def fn's will usually eek out performance over λ expressions but not by anything really noticeable unless you have some order of op stuff going on. If you really want to make this fn sing, use a generator, ala my fork.

While the tests might only provide a singular entry, the datatypes in use don't actually restric the number of entries which suggests the intent of the code is to also support multiple entries, so I think the min would be important, but ultimately, I didn't write the original stuff. Regardless, if there should only ever be one entry, then the code should only provide datatypes and paths that allow for a single entry, otherwise, it should be 'defensive'.

In Python 3.10, I'm failing a depth 2 test: Should return false for non-equal trees.

I've verified that my code returns false, but the test fails with 'True should equal False'

The tree structure is

 3       4
|  \     |  \
1   1    1   1
| \ |\   | \ |\
()()()() ()()()()

Am I missing something?

Update: I've hard-wired the code to check for this tree, verified the branch with prints statements in the log, but the test fails regardless of whether I return True or False

Short code isn't 'good code' if it's several orders of magnitude slower at the end of the day.