So now you have made me curious, I started reading about it. Some people expressed a view that IEnumerable  only guarantees an enumeration and doesn't guarantee the order of execution (even if ordered beforehand). However, as I read it, its the same execution as list because the latter inherited the former. Which is correct?

Err, both, if I understand the question. An IEnumerable method returns an IEnumerator which has a MoveNext method that returns the next item. Calling that method is what triggers the enumerator to start doing its job. If you use a foreach loop, C# calls MoveNext for you until the enumerator is exhausted.

Each Enumerable method, such as Select or Except or OrderBy, returns a different IEnumerator implementation that stores any state that it needs plus the next IEnumerator along in the chain. For example, Select takes a projection function that maps from one type to another, and uses it to transform all of the elements of the enumeration into the result type. You could implement its IEnumerator approximately like this:

public class SelectEnumerator : IEnumerator
{
    private IEnumerator _inner;
    private Func<TSource, i32, TResult> _func;
    private TResult _current;

    public bool MoveNext()
    {
        _current = null;
        return _inner.MoveNext();
    }

    object IEnumerator.Current
    {
        get
        {
            if (_current) return _current;
            return _current = _func(_inner.Current);
        }
    }
}

The Where method is similar, but it only returns elements where the predicate returns true. You could write it approximately like this:

public class WhereEnumerator : IEnumerator
{
    private IEnumerator _inner;
    private Func<TSource, Boolean> _func;

    public bool MoveNext()
    {
        foreach (var e in _inner) {
            if (_func(e)) {
                return true;
            }
        }
        return false;
    }

    object IEnumerator.Current
    {
        get
        {
            return _inner.Current;
        }
    }
}

So to answer your question, the various Enumerable methods that you call only create these IEnumerator objects, and each Enumerator only runs enough code to get you the next item along. The execution of all of the Enumerators is interleaved, since each one calls the next one in the chain at least once. With some data sources the order of the results might vary, since data might come in from a database in an arbitrary order (for example), but since you are starting with a List then that will never happen. The elements returned by the enumerator will always be in the same order as they were in the original list, at least until you sort them.

EDIT

I just ran an experiment for the missile salvo list on the fleet window, which I just updated.

[…]

I ran both functions several times and in every case, the List version is faster than the IEnumerable version. It may be that the IEnumerable is faster to create, but the List seems to be faster to use. Maybe because everything is preloaded into memory for the List, whereas the IEnumerable has to retrieve the information as needed.

Of course I would need to see all of the code, and to know how you measured the performance to be able to say why that might be. See below…

Further reading suggests that every time you access a method or property of the same element within an IEnumerable foreach, it has to retrieve it again. A list already has it in memory.

Note quite. Notice that IEnumerator has a property called Current that holds the current value. They are all written so that they don't do any extra work if you retrieve that value more than once; you can see how I did that in SelectEnumerator above. And anyway, since you use a foreach loop C# is assigning that value to a local variable anyway. It doesn’t have to go back to the enumerator at all even if you access multiple properties or methods on the value that local variable holds.

So its likely that IEnumerable  is faster if you are doing very little with the data you enumerate, but List is faster if you want to access each element more than once (either in multiple iterations, or getting using multiple properties/methods for each element of a single iteration).

This is definitely true. If you need to multiple values from the enumeration at once, for example the nth − 1 element as well as the nth, then you need to write it in such a way that the enumerator doesn't have to be reset back to the start and work it’s way back down to the previous element. It should be fairly hard to make that mistake just by using foreach loops though.

I tend to explore using individual explorers. Given the distances involved, fuel efficiency is key.
Research a bunch of engine techs, plus 8:1 or 10:1 jump engine techs, then make a size 25 commercial engine that is as fuel-efficient as possible (even if it is 50% slower). Slap on 1-2 survey scanners and 1-2 jump point sniffers, enough fuel, supplies, and deployment time to last over a decade, then mass produce those using multiple shipyards/slipways.
Order Automate survey then jumppoint survey.
It has a slow start but as their numbers grow it gets faster and faster as you only occasionally have to go back to refuel.

QOL Suggestion:

Naval Organization window, Fleet -> Movement Orders tab
Double clicking any order in the list of the fleet's current orders should remove all orders after that one (perhaps with a confirmation prompt).


Sometimes I need to trim a long list of orders back to a specific point.
Repeatedly clicking the Remove Last button is the only way to do it currently.
Sometimes that's a LOT of clicks, and sometimes a user overclicks and then has to re-create the unintentionally removed orders.

Seconded as I actually run into this issue often when I repeat a set of orders many times and find I miscounted or the conditions changed.

Join Fleet and Begin Overhaul

I've added a new order called 'Join Fleet and Begin Overhaul'.

This functions as a combination of the Join Fleet and Begin Overhaul orders, with the moving fleet joining the target fleet and immediately entering overhaul. This order will only be available if the target fleet is in a maintenance location and the overhaul will only start if the target fleet is still in a maintenance location when the moving fleet joins it.

I have a method that requires approximately one manual order per survey ship per system.

Specifically, for each system explored:
One manual move order per survey ship
One manual send message order for one survey ship
One manual move order for a jump tender

(Occasionally you have to give manual geosurvey orders for far outlying bodies; this is true no matter what you do.)


Requirements:

1) You are surveying systems that do not already have stabilized jump points (which is usually the case, right?)
2) You are willing to make survey ships without their own jump drive

Standing order to use:

1) Survey Next Three System Bodies or Locations

Procedure:

Assign a jump tender to each survey group.
When entire survey group is in the same system, move the tender to the jump point of the adjacent system that you want the group to survey next.
When a survey finishes standing orders, give it a move order to the next system.
If it is the last survey ship to finish, give it also a send message order like "can move tender now"
When you receive that message, move the tender to the jump point of the next adjacent system you want to survey (if no jump points yet found, wait until one is found).


You might want to have multiple tenders per group, so that when you reach a dead end system, you can position the tenders appropriately for the surveyors to backtrack to the next target system individually, rather than waiting for the entire group to travel with a single tender.