Algorithm to find path between nodes
The code you have there may accomplish the task you have in mind for it, but it's not useful for a &quot;real world&quot; usecase.
That's because usually you'd want to be able to run an algorithm like this multiple times on the same graph, maybe even concurrently.
The problem that's posing itself here is that Node mixes two concerns: Representing the graph and traversing it.
Storing the Visited state inside the Node is really useful, but it's also quite limiting. As such you could greatly benefit from storing visited Nodes as a Set instead to separate traversal from representation.

There's also some minor optimization possibilities:

Replace the foreach in the Node constructor with AddRange

Once .NET 5 releases (or you switch to .NET Core) You can slightly simplify the while loop in the BFS itself using searchQueue.TryDequeue(var (node, length)).

Storing visited nodes in a HashSet (or similar) enables reformulating EnqueueNotVisitedChildrenNodes as:
foreach (var child in node.Children.ExceptWith(visited))
{
    searchQueue.Enqueue((child, length + 1));
}

This reformulation of course then messes with the visited state of nodes you didn't actually visit yet, since you set Visited when you enqueue the node, not when you actually visit it.
This flagging visited when enqueueing utterly breaks as soon as you start working with &quot;weighted graphs&quot;, where the smallest number of edges may not be the optimal path (like the following)
(A) -(1)- (B) -(1)- (C)
  \                 /
   -------(5)-------

Going from (A) to (C) via (B) is cheaper than the direct route here :), if your real target was a node (D) that's only connected to (C), your current code would route you through (C) because the shorter route through (B) would be ignored since (C) already counts as visited when you dequeue (B).



Overall this code is really nice and clean, but it lacks general applicability (which is not a bad thing in itself).