Move from a node to another of Path2D

Split the segments of your one big curve into separate curves, each containing only one segment. Then do the path follow thing consecutively on those one-segment curves.

Catapult Have you tested this? Looks like it may work but beware because this approach could introduce floating point precision bugs. You're searching for the exact point coordinates by value. For some numbers it can result in a miss even if point coordinates seemingly match, due to nature of floating point roundoff. It's generally not a good idea to compare float number using == operator.
So you should test this excessively before using it in published code.

Btw, splitting curves is pretty straightforward:

func split_curve(curve: Curve2D):
	var out_sub_curves = []
	for i in curve.point_count-1:
		var sub_curve = Curve2D.new()
		sub_curve.add_point(curve.get_point_position(i), curve.get_point_in(i), curve.get_point_out(i) )
		sub_curve.add_point(curve.get_point_position(i+1), curve.get_point_in(i+1), curve.get_point_out(i+1) )
		out_sub_curves.push_back(sub_curve)
	return out_sub_curves

Catapult PackedVector2Array::find() likely uses == to check if values match. Floating point precision errors are nasty, chaotic and hard to reproduce after the fact. For example, everything could seemingly work fine when your coordinates are in the order of magnitude close to 1.0. Then after three months of development you decide to expand your maps so now coordinate ranges get much larger. Due to nature of floating point representation, you'll lose precision, comparison may start to fail sporadically and you end up going mad wondering how code that worked flawlessly for three months started exhibiting erratic behavior out of the blue.

get_baked_points() will return tessellated points. Tessellation involves calculation during which some precision could be lost, resulting in your tessellated (baked) points that should coincide with original curve points to end up slightly off. It's an extremely small precision error that could happen, depending on actual numbers and calculations involved. But when it happens it can cause the == operator to return false when you're expecting it to return true. Consider this example:

var a = 1.0 / 3.0
var v = Vector2()
v.x = a
print(v.x == a)

You'd expect this to print true, right? Well, try to run it and see what happens.

Catapult You're missing the point. Using integers carries exact same risks. It's not a matter of "engine's float management", but rather a side effect of floating point representation itself, and it happens across platforms and languages. The precision we're talking about here is negligible as far as most calculation results are concerned. You can safely lunch Ariane 5 with that kind of precision margins. However when comparison via operator == is involved, the precision mishaps can break your code. It's sort of a rule of thumb that if you want to produce bulletproof code you should never ever use == on floats, or rely on code that you suspect might use == on floats.

In Godot, all vector/matrix data components are 32 bit floats. Even if you assign integers to it, they'll be converted to floats. Doing calculations with 32 bit floats and then using == to compare results is always risky. Precisely because it appears to work without any problems almost all the time, until a case comes that it doesn't, producing hard to detect bugs.

There's a reason why all Godot's vector types have is_equal_approx() method. This method should always be used instead of == when comparing float data. Now PackedVector2Array::find() probably uses it internally but we don't have a guarantee on this. It could be implementation dependent. If it uses operator ==, the find() will fail in some cases where you think it shouldn't.