Move from a node to another of Path2D

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.

Catapult It probably is safe to use. But again, the documentation does not explicitly guarantee it. So we can't be sure. IMHO it should mention how it internally determines if two vectors are equal.

And you're not only an engine user. You're a software developer as well. And every software developer should know how floats operate. That's why the article @Megalomaniak linked is called What Every Programmer Should Know About Floating-Point Arithmetic

Imagine you want to port your code to a different language or need to use a different type of array. In c++ for example, all find() methods for all standard array types always default to using == for comparison.

I did a quick test and it appears that find() in packed arrays indeed uses some epsilon when comparing values. However it can still bite you in the butt when you least expect.
Consider this piece of code:

	# add an integer value to float32 array
	var a = PackedFloat32Array()
	a.push_back(1)
	
	# do some calculations that should result in the same value we started with 
	a[0] -= 1.1
	a[0] += 1.1
	
	# prints true as expected
	print(a[0] == 1)
	
	# prints true as expected
	print(is_equal_approx(a[0], 1))
	
	# prints 0, the value is fond in the array as expected
	print(a.find(1))

Now check this out. Exactly the same code, only that addition/subtraction in our dummy calculation swapped places. The code now behaves differently for seemingly no apparent reason:

	# add an integer value to float32 array
	var a = PackedFloat32Array()
	a.push_back(1)
	
	# do some calculations that should result in the same value we started with 
	a[0] += 1.1
	a[0] -= 1.1
	
	# prints false
	print(a[0] == 1)
	
	# prints true
	print(is_equal_approx(a[0], 1))
	
	# prints -1, the value is NOT found in the array
	print(a.find(1))

That's the kind of gotchas I was talking about.

But there's more If you change 1.1 to 1.2 in the second piece of code, things now again work as expected. But if you change it yet again to 1.4 - the bug is back.
Is my computer possessed by a demon?