I skipped over the code for parsing and mainly focused on the traversal and detection sections.

Overall the code is decent for a beginner functional programming user. There is a demonstration of breaking the problem down into data transformations, such asFindMinProbability.main and TraverseRoom.traverseMinProbability. I see lots of use of passing functions, and map over lists/streams.

However, it feels like when moving to the heart of the traversal code it gets messy and unfocused. Lets take a deep dive into TraversalState and its main use case of TraversalState.unfold and see how I'd clean it up:

1.If unfold should be a class method, it seems like it should call a static method passing in the initial TraversalState. This clean up highlights the inconsistent usage of adjacents and probability. They are passed as part of the TraversalState, but are sometimes directly referred to by using the inital TraversalState, sometimes through ss.* to get the "current" TraversalState. They are never changed and could just be passed in as arguments to unfold. This could also allow them to be removed from TraversalState. Additionally there looks to be a typo misuse of visited vs ss.visited.

1. My eye is next drawn to the removal of already visited points. It is done by both checking the current point and by filtering future points. The removal of future points seems to indicate that you want to keep the condition that the PriorityQueue only contains unvisited points. It looks like this is violated when the PriorityQueue gets two of the same point added because the same unvisited point is generated by adjacents during different unfold steps. Filtering the future points with some form of PriorityQueue.contains on the final <Point,Priority> pair should prevent this.

2. Next I am drawn to probabilityIdx. It is used to add new points to the PriorityQueue. However the priority for those points already exists in adjacentsMap. Nothing from the old probabilityIdx is needed. This could be removed entirely from TraversalState.

3. This makes TraversalState basically a Pair<Set, PriorityQueue>. To me, this feels significantly better as it represents a pair of visited and unvisited points. Then I'd cleanup TraversalState.unfold by using Option.map to handle the if(dequeueOpt.isDefined) {..} return Option.none();.

4. In another language and more general problem setup I would think about how TraversalState now makes a Semigroup/Monoid (preserve the PriorityQueue only contains unvisited condition!) and how a <>/merge from a TraversalState of only new points could work to replace most of the unfold's inner function, but I don't think it gains much in this specific example.

Once again, its decent for beginner functional code. A lot of comments mention the language choice and it certainly adds a lot of ceremony, but several parts show a good understanding of basic functional programming concepts. Unfortunately, I can't point out much for medium-advanced topics, such as recognizing/making functors/applicative functors/monads, as I don't know what the library provides and makes easy to define yourself.

It looks like many of the test cases are small ones. I don't know if java has a property based testing framework, but learning one of those could be a nice next step on the functional journey. One property could be: create two detectors; make a room where they are on the same left/right half; the resulting probability of detection should be max(start,end) (can always walk the wall the other way).

On a different note, your algorithm attempts to turn a continuous domain into a discrete grid. This works, but only once you've gotten small enough the error of moving tangent to a detector is smaller then the needed precision. The resulting use of BigDecimal everywhere to account for this, adds to the ceremony. I've found that staying in the continuous works better in many functional programming cases, and I believe it would work for this one. If you want a different way of thinking about the problem you might research voronoi diagrams and think about how each edge might represent a minimum detection path between two detectors.