Unexpected behavior of traversedVertex and strategy breadth_first when traversing graphs

[giacomoParigi]

I have two problems with the functioning of the TRAVERSE method on a graph. The three scripts attached are three simple examples to reproduce the problems (use with bin/console.sh). The three example graphs are structured as a diamond: four nodes connected with five or six edges (i.e. the four sides of the diamond and one or two edges cutting in the middle) in different directions, with a few unimportant leaf nodes added to verify the correctness of the query. Two opposite vertices of the diamond are always of the same class (called 'A').

1. The first problem is about the traversedVertex function:
   I want to traverse the graph from one vertex of the diamond to the first vertex of the same class (In the examples, the opposite vertex of the diamond). In the following query I have a check on the class of traversedVertex(-1) and it works fine, but if I get the same value from an outer select it gives an unexpected value (namely, it always uses the vertex 'out' of the last traversed edge, irrespective of the direction in which it traversed it). The query is a simplified version of the ones in the scripts, to make it more readable.

SELECT $current.traversedVertex(-1) as lastTraversedVertex FROM (
   TRAVERSE * FROM (
      SELECT FROM A WHERE name = 'A0'
   ) WHILE  (traversedVertex(-1) = traversedVertex(0)
   OR traversedVertex(-1).@class <> traversedVertex(0).@class)
   LIMIT -1
) LET $start = $current.traversedVertex(0)
WHERE (out.@class = $start.@class and out.@rid <> $start.@rid)
OR (in.@class = $start.@class and in.@rid <> $start.@rid)
LIMIT -1;

The last WHERE condition is a workaround for this problem. In theory, it should be possible to use just 'WHERE $current.traversedVertex(-1) <> $start.@Rid' to get the correct result.

2. The second problem is about the breadth_first strategy:
   if I add $path to the projections of the previous SELECT query to verify actual paths traversed (note that the TRAVERSE is undirected), it shows only two paths between the two vertices of the diamond. The first is the shortest (just one side of the diamond) and the second is the longest, cutting through the middle of the diamond. This could be correct in a depth_first traversal, since it does not follow paths that encounter already traversed vertex. However, if I add 'STRATEGY breadth_first' to the TRAVERSE (see the second query in the scripts), it should return the two short paths that follow the sides of the diamond. It doesn't in any of the examples. The only way to get both the short paths is to limit the TRAVERSE with '$depth < 4' (third query of the scripts), but it clearly defeats the original purpose of the query...

Are these two problems a matter of wrong comprehension of the TRAVERSE method or a bug?

TraversedVertex_BreadthFirst_check0.txt
TraversedVertex_BreadthFirst_check1.txt
TraversedVertex_BreadthFirst_check2.txt