Similar pairs would imply some approximate matching rather than exact whole word matching.
Perhaps ignoring case by mapping to lower case:

var seenWords = Arrays.stream(words).map(String::toLowerCase).collect(Collectors.toSet());

But similar pairs is also not quite right -- more like "count duplicates".
Otherwise the similar pairs eg in
{"Volvo", "Volvo", "BMW", "Mazda", "BMW"}
would be 2 -- a pair of Volvos and a pair of BMWs.

And how many pairs are there in { "Volvo", "Volvo", "Volvo", "Mazda" } ?
Actually 3 - there are 3 ways to pick a pair of Volvos from the list 😆!

I disagree that positive lookaheads (?=...) make the problem easier. They would make possible solutions generating answers that are more efficient/concise, but the original complexity still needed for the powers of single primes (eg 17), and could allow for larger factors to be tested.

Integer ops or not, the point is that the constants can be reduced as in the examples above. And yes, taking into account the integer division, (a * (3 / 2)) == a * 1 == a. But (a / 2) * 3 can not be simplified. So these optimizations should be accepted in the solutions, particularly for a 1-kyu level.

Nice Kata, but for a 1-Kyu level the requirements for the optimization (pass2) could be stricter.
Eg most of the soltions submitted will reduce ((1 + 3) + x) to (4 + x), but additional cases that should be achievable are:

• ((x + 1) + 3) = (x + 4)
• ((x - 1) - 3) = (x - 4)
• (0 + x) = x
• (x * 1) = x
• (x - y - z + 10 / 5 / 2 - 7 / 1 / 7) = (x - y - z + 0) = (x - y - z)

Clearly there are always multiple solutions, but prioritising the possible answers as follows seems to succeed:
(1) Solutions that don't involve fractions.
(2) Solutions that refer to the "first seen" variables in the list of examples.

Hi Clair. If the original problem is from "a company's coding assessment", then maybe they also want to see what you do with an inadequately stated requirements specification, which is a very common real-world situation!
If they can't or won't clarify, then I would simply state your assumptions and provide your solution that passes.
Otherwise if you have more automated tests you could also try some different assumptions (eg there must be as many '-' as there are '.') and modify your code.
BTW, you really don't need a 'stack' in your code since you only need to keep track of how many '.' you have seen -- so a simple int is enough.
Good luck!

The description of "input1" and "input2" seems somewhat C language centric, and input1 is quite redundant as can be seen in your initial code -- it is never referenced. Better to just describe the single input as being the "Sequence of strings, each representing a new message in the set" and leave it to the language specific variant whether that is an array, a list, a length + a pointer, or whatever.
Another example with extra dashes might clarify that unmatched '-' are ok, just no unmatched '.'. Assuming that is the case, then:
".---.-" is OK (extra dashes but every dot still has a corresponding dash)
".--..-.-" is not OK (extra dashes, but not enough dashes after the 2nd and 3rd dots)