Tested on GN 549249 but surely still the same on trunk.

Simplest reproducer:

assert({a=1} == {a=1}, "")                                                      

The more problematic result of this is that redundant imports are no longer harmless when the import sets a variable to a value including a scope (e.g. to a scope or to a list of scopes, etc.).  There is no "redundant import" logic per se, just the logic that complains about imports clobbering variables unless the values are identical.  Since the test for identical values fails when scopes are involved, redundant imports involving scope-typed values are flagged as clobbering the previous value.  

The failure mode for this is especially confusing when the variable in question is a build argument whose default value doesn't include a scope but whose args value does.  Then it cites the redundant import as clobbering, but points to the same place in the args.gn as both the first and second definition.