I have parent objects whose children are used as pathing points. The children are named Waypoint1, Waypoint2, etc. In the outliner they are ordered correctly, but when getting the children using:
if( Path->IsValidLowLevel() )
{
Path->GetAttachedActors( Waypoints );
for( int i = 0; i < Waypoints.Num() / 2; ++i )
Waypoints.Swap( i, Waypoints.Num() - i - 1 );
}
they are ordered:
I’d be really careful doing it just by the outliner. The GetAttachedActors function is recursive, so messing with nesting in that will totally break your stuff, and I think the way AttachChildren ends up filled depends on the order the components actually finish their construction and then attach themselves to their parent.
You could get away with making it an array of vectors and use the widgets as the waypoints? Or maybe consider making your waypoint type a struct instead of an object so you can get around uobject/component construction weirdness? Otherwise you might have to actually set up the order at runtime (like on BeginPlay or something). 
Oh that kinda stinks because I was using static mesh spheres as my waypoints and setting them to not render in game - this way I could place them by hand.
Its odd that they do come in ordered by the first number every time but not the second, i.e. wp1, wp10, wp2, wp20 etc.
It kinda stinks in this case, but it’s a really good optimization in a bunch of other cases, especially once you start having more than one type of component. What you could do if you wanted to hack together a chain of waypoints is make them children under the one that comes before them, but it’s probably easiest/safest to just have an array of vectors as a member and use 3d widgets to place them.
In C++ you add the MakeEditWidget tag, or in BP you just use Show 3d Widget.