Currently in cases like these the second branch is not marked as unreachable:
case n {
10 -> todo
1_0 -> todo
}
case x {
1.0 -> todo
1.00 -> todo
}
This happens because the comparison is done on the raw string value rather than a parsed number. Implementers may want to peek at #5001 which tackled the same issue for floats in useless comparison warnings (1.0 == 1.00)
There exists a separate issue for bit array patterns: #5013