Алексей Павлов

вообще то видно, что Image_Name_List.Count = 1 при этом не видно i, если i больше 0 (да да, по традиции сишных языков, все индексируется с 0) то именно такая ошибка и возникнет

что такое Capacity см тут Свойство List.Capacity (совсем коротко - это сколько зарезервировано ссылок на данный момент, но не сколько есть)

ps если все еще не понятно - актуальный размер это Свойство List.Count

Visual Studio
Rider

P.S.

Аля drug&drop

А это уже уголовно наказуемо )))

1. Да, задача может исполниться где угодно. Более того, вы не поверите, но некоторые таски вообще могут нигде не исполняться, т.к. исполнять нечего (см. п. 5). Таск - это прежде всего абстракция значения, которое будет получено в будущем, и для получения которого возможно нужно что-то посчитать или просто подождать. См. futures and promises.
2. Ну не обязательно в новом потоке, может быть выполнится и в существующем потоке если в пуле потоков есть свободный.
3. Асинхронные операции ввода-вывода называются так потому, что выполняются через асинхронное API операционной системы. Нет никакого смысла использовать асинхронную операцию, но делать это в отдельном потоке созданном специально для этой операции. Потоки нужны прежде всего для того, чтобы эффективно нагружать исполнителей, т.е. процессоры (в том числе разные их ядра).
4. Можно в новом, можно в потоке из пула. Так или иначе, если операция предполагает именно расчёты, а не ожидание ввода/вывода, то безусловно это тот случай, когда имеет смысл переложить нагрузку на другой поток.
5. Если представлять таск как одну из сторон "трубы", по которой прилетит результат асинхронной операции, то Task - это принимающая сторона, а TaskCompletiotionSource - передающая (производящая результат) сторона. Когда вы создаёте таск из кода который нужно выполнить, этот код становится передающей стороной. Но Task абстрагирует любую асинхронную операцию, не только ту где нужно долго что-то считать. Возможно вам нужно дождаться одного байтика из сети, и операция будет считаться завершенной. Во всех тех случаях, когда вы хотите самостоятельно "произвести" результат для какого-то таска (а сам таск отдать "наружу" другому коду, например вернуть из функции), вы можете использовать TaskCompletionSource.
(Кстати, в C++ принимающая сторона называется future, а передающая (производящая) - promise. В JS принимающая сторона называется Promise, а передатчиком является функтор).

page_item:
    path: /{parameters}
    defaults: { _controller: AppBundle\Controller\Page\PageController:itemAction }
    requirements:
        parameters: ".+"

public function itemAction(Request $request, $parameters)
{
    $parts = explode('/', $parameters);
    // ...
}

Этот код должен находится в самом конце списка роутов, т.к. он будет соответствовать любой ссылке.

Я делаю тоже самое, и тоже 2 года.
Но вот мне все также интересно, по вечерам читаю книги, на выходных смотрю видео.

Развиваться можно бесконечно.
Попробуйте почитать про алгоритмы и структуры данных, начнете смотреть на привычные вещи другим взглядом.

1) Род Стивенс - "Алгоритмы. Теория и практическое применение".
2) Джон Маккормик - "Девять алгоритмов, которые изменили будущее".

Выучите SOLID (Боб "Принципы, паттерны и методики гибкой разработки"), GOF (банда 4х, хватит https://metanit.com/sharp/patterns/), GRASP (Крэг Ларман - "Введение в объектно-ориентированный анализ, проектирование и интеративную разработку") наизусть, прочитайте книги авторов.

Работа работой, делайте свое дело.
А в свободное время учите и читайте то что вечно, или почти вечно - алгоритмы, паттерны и т.п., то что можно применить где угодно и на чем угодно. Не забивайте голову неиспользуемыми фрейворками (приходят и уходят) и другими языками программирования на которые не собираетесь переходить.

Я посмотрел основные принципы ООП с точки зрения Алана Кея и не могу понять, чего он хотел.

Неудивительно. Изначально ООП было прежде всего идеей и не имело формального описания, такого как реляционная алгебра для РБД. То, что не имеет формального описания может быть по-разному трактовано и понято, или не понято вовсе.

Да. Этого нет.

Ошибаетесь. Есть аналог "сообщений" - это методы объектов. Вызов метода - это аналог посыла сообщения. Просто вы не привыкли рассматривать это с такой точки зрения. Например, в Objective C, в котором ООП смолтоковского стиля, так прямо и говорят. В языках с Simula-подобным ООП методы не называют сообщениями, т.к. в отличие от Smalltalk-стиля выбор кода для вызова (обработки метода/сообщения) выполняется компилятором, а не самим объектом.

Каждый объект имеет независимую память, которая состоит из других объектов

Пожалуй здесь речь идёт об инкапсуляции.

Стоп. Разве это не то, что я написал в пункте 4?

Нет. В пункте 4 вводится само понятие классификации - что среди неупорядоченного набора всевозможных объектов вы выделяете подмножества объектов, "похожих" друг на друга. Здесь ещё не идёт речи о том, будут ли у них общие методы или ещё что-то конкретно. Речь о самой идее выделения объектов во множества по каким-либо признакам. В пункте 5 уже делается заключение, что если уж мы выделили некоторое подмножество объектов, то грех этим не воспользоваться и не задать одно и то же поведение сразу для всего подмножества (грубовато описал, но как то так и есть).

Если у меня есть класс Dog, описывающий собаку, то от какого мифического единого общего класса она должна наследоваться?

System.Object. Да, вы уже от него унаследовались, прямо или через других предков. С точки зрения среды исполнения не всё чем вы оперируете, является объектом, например примитивные значения. Однако с точки зрения языка можно сказать что int "является объектом" т.к. значение int может быть приведено к типу object. От себя лично скажу, что целесообразность концепции "всё - объект" весьма сомнительна по ряду причин.

Насчёт статичности это уж вам решать, а вообще проще всего в корутины передавать колбэк:

using UnityEngine;
using System;
using System.Collections;

public class Example : MonoBehaviour
{
    private void Start()
    {
        StartCoroutine(DownloadFile("url", text => DeserializeConfig(text, () => Debug.Log("Done"))));
    }

    private IEnumerator DownloadFile(string url, Action<string> onComplete)
    {
        using (WWW www = new WWW(url))
        {
            yield return www;
            onComplete(www.text);
        }
    }

    private void DeserializeConfig(string text, Action onComplete)
    {
        Debug.Log(text);
        onComplete();
    }
}

При такой схеме очень быстро выстраивается лесенка из вложенных делегатов, но, по крайней мере, она выполняет свою работу. Лучшим решением будет использовать промисы или UniRx, тогда будет проще управлять потоком.

Блокировка IEnumerator зависит от тяжести операций между yield'ами, корутины выполняются в том же самом потоке, они просто позволяют растащить выполнение кода между кадрами.