The condition checks if both contacts are either advTypeRepeater OR advTypeRoom. However, based on the PR title "Show overlaps in public keys of repeaters" and the English localization "Repeater Key Overlaps", this feature appears to be specifically for repeaters. Including rooms in the overlap detection may be intentional, but it's inconsistent with the user-facing messaging which only mentions repeaters. Consider either:

1. Updating the UI text to mention both repeaters and rooms
2. Restricting the check to only repeaters if rooms were included by mistake

This code has O(n²) time complexity because the overlap detection runs a full scan of the contacts list for every contact being filtered. For large contact lists, this could cause noticeable performance degradation.

Consider optimizing by:

1. Pre-computing overlaps once before the filtering loop
2. Building a map of first-byte to contacts for O(1) lookup
3. Or moving the overlap computation outside the filter function and storing it as metadata on contacts

The tooltip strings "Path Trace", "Build Return Path", and "Remove Last Point" are hardcoded in English instead of using localization. This is inconsistent with the rest of the codebase which uses context.l10n for all user-facing strings. These should use localized strings from the l10n files.

This line is commented out but left in the code. If this spacing adjustment is no longer needed due to the button changes, the commented line should be removed entirely to keep the code clean. If it might be needed later, add a comment explaining why it's kept.

The code accesses publicKey.first without checking if the Uint8List is non-empty. While publicKey is a required non-nullable field, an empty Uint8List could still be passed, which would cause a runtime error when accessing .first. Consider adding a safety check or documenting that publicKey must never be empty.

The code calls substring(0, 2) on publicKeyHex without checking its length. If publicKeyHex is shorter than 2 characters, this will throw a RangeError. While public keys are typically of a fixed length, consider adding a safety check or using a safer substring method like substring(0, min(2, publicKeyHex.length)).

The filtering logic has several design issues:

1. When mapShowOverlaps is enabled, it overrides individual node type filters by including repeaters and other nodes even if those filters are disabled (lines 530, 541). This means users will see repeaters/other nodes even if they've explicitly disabled those checkboxes in the UI. This creates a confusing user experience.

2. The addContact boolean is set by multiple independent conditions, making the logic hard to follow. A contact is added if ANY of the node type conditions are true, which isn't immediately clear from the structure.

3. The overlap detection at lines 556-559 acts as an exclusive filter - when enabled with no overlap found, it overrides the earlier addContact = true decisions. This means mapShowOverlaps acts as "show ONLY overlaps" rather than "highlight overlaps".

Consider refactoring to make the intent clearer, perhaps separating "which nodes to consider" from "which nodes to display" logic. Also consider whether overriding individual node type filters is the desired UX.

Guard path trace start when self location is unavailable

The radar action now force-unwraps connector.selfLatitude and connector.selfLongitude, but those fields are nullable in this screen (there are nearby null checks before rendering self-position markers). If the user opens the map before self info is populated, or if the device has no valid self location, tapping path trace will throw on the ! and crash this flow. Please gate this button/action on non-null coordinates or keep the previous start-without-self behavior.

Useful? React with 👍 / 👎.

Keep legend counts consistent with key-prefix filtering

The legend is now built from filteredByTime, while markers are built from filteredByKeyPrefix, so enabling key-prefix filtering hides nodes on the map but the legend still counts them. In practice this makes the node totals inaccurate whenever mapKeyPrefixEnabled is on and can report nodes that are intentionally filtered out from the current view.

Useful? React with 👍 / 👎.

dart:collection is imported but doesn't appear to be used anywhere in this file. With flutter_lints, this will be flagged as an unused import and can fail flutter analyze.

Remove the import or use the specific collection type you intended to add.

The new weighted anchor averaging logic divides by anchors.length, but the accumulated lat/lon values are no longer a simple sum (they include weights and treat the first anchor differently). This produces a biased value that is also incorrectly scaled (it will drift toward 0,0 as anchors increase).

If you want a weighted average, track weightSum and divide by that (and apply the intended weight to the first anchor as well).

clearAllHistories() calls _storage.clearAllPathHistories() which returns a Future<void>, but the future isn't awaited or wrapped in unawaited(...). With flutter_lints this is typically flagged by unawaited_futures, and it also means any errors during preference clearing will be dropped.

Make clearAllHistories async and await the call (or explicitly wrap it in unawaited(...) if fire-and-forget is intended).

This settings tile introduces hard-coded English strings (title/subtitle). The rest of the screen uses l10n, so this will be untranslated in all locales.

Also, this performs a destructive action without any confirmation dialog. Consider using localized strings and showing a confirm dialog (similar to reboot).

The @path_routeWeight metadata placeholders don't match the message template. The string uses {weight}/{max}, but the placeholders define value and max. This can break localization code generation/runtime formatting.

Rename the placeholder key to weight (to match {weight}) or update the message template to use {value} consistently.

The Path Trace (radar) button unconditionally force-unwraps connector.selfLatitude/selfLongitude when starting a trace. If the device location isn't set yet, this will throw at runtime.

Disable the button until both values are non-null, or pass a fallback position (e.g., current map center).

_filterContactsBySettings checks for overlaps by scanning the full contacts list (where(...).firstOrNull) for every contact, which is O(n²). On larger contact lists this can noticeably slow marker building (and it runs every rebuild).

Consider precomputing a map of firstByte -> count (or a set of overlapping first-bytes) once per build and using that for O(1) overlap checks.

The UI copy says "Clear all path data from contacts.", but connector.deleteAllPaths() only clears local PathHistoryService cache/storage (it doesn't reset contact/device path overrides). This makes the action's effect unclear to users.

Update the subtitle to accurately describe what will be cleared, or extend the action to clear the additional path state it claims to remove.

In the contact settings dialog, connector.setContactFlags(...) returns a Future but it's called without await/error handling. With flutter_lints this may trigger unawaited_futures, and failures will be unhandled.

Make the callback async, await the update, and consider showing an error/snackbar on failure before closing the dialog.