Is there anything immediately obvious here?
If I run it like this I get 5 points… But my point[4] is not offset.
if I run it like this I get 2 points!!
And if I run it like this:
Question… what on earth is the difference between the two code blocks??
I cannot work out what’s going on.
Best guess: Object types might be int for one and double for the other.
Is there some form of object permanence with the Dynamo points across runs? You modify the center_point (global value) in the function but if the input IN[0] doesn’t update the point gets modified again (assuming the Add operator works ‘in-place’)
Edit I did some testing - my theory is unlikely as Vectors and Points aren’t updated in-place but rather return the result of the operation
This was the issue. 
def calculate_final_point(offset, vector_handle):
final_point = hinge_point.Add(vector_handle.Scale(-offset))
return final_point
It worked with
offset = 300.0
but not with
offset = 300
Seems a bit silly… but… 
Generally Python doesn’t like mixing data types, and CPython handles math with integers and doubles quite differently than IronPython. As a result it’s best to check for such things as you go.
Be nice if Dyno coloured them differently. I love how a string is orange and a number is blue… Be great to have an extra differentiation of colour.
Good feedback for the wishlist. 
But from Dynamo’s perspective, the conversion is handled. Math with any type of number just works. As such there isn’t very much value in Dynamo adding another shade of blue here. I guess it’d matter for something like setting a parameter value, but I can’t think of anything Dynamo native that it impacts offhand (even List.GetItemAtIndex rounds a double to an int). As it is Python that’s performing differently you need to convert to a consistent type there to get the consistent results you’re after. Think of it sort of like unwrapping a Revit element before using the Revit API on it.