Saboteur

существует множество РАЗНЫХ лицензий для открытого кода.
Читайте лицензию, которая идет вместе с кодом. В некоторых случаях он свободно распространяется, в некоторых запрещено использовать в коммерческих продуктах без согласования с автором.

dokuwiki, mediawiki
Парочку плагинов для кода и визуальный редактор поставить, и все.

нет никаких стандартных способов. Для foreach хранить еще какую-то дополнительную переменную-счетчик - это лишние операции, поэтому логично, что втихую никто не будет такими операциями нагружать обычный цикл.
Нужно считать - делайте счетчик, как вы сами привели в примере

Я бы не рекомендовал вам пользоваться советами при таком общем вопросе.
Крупный проект может пользоваться очень маленькой базой.
Вопрос маленькой и большой базы весьма относителен.
И вообще проконсультируйтесь с архитектором продукта, который собираетесь разрабатывать, все зависит от проекта, а не размера базы - бывает есть смысл разделять, бывает есть смысл ставить кластер.

Для чтения по абсолютному пути проблем не будет.
Некоторые проблемы могут быть при добвлении новых файлов, updatedb и др.
Но лучше разбить на несколько папок, вы же все равно полный путь в базе храните.

чем не нравится встроенная блокировка в винде?
Трукрипт никуда не пропал. Вместо него можно еще veracrypt использовать - тот же трукрипт.

облако - виртуальный сервер в кластере железных серверов.

Отличие обычного виртуального сервера от облачного виртуального сервера - ты не знаешь на каком именно железе крутится твой облачный VPS сервер - он может легко мигрировать с одного хоста на другой, с одного сервера на другой или на кластер серверов, масштабируется прозрачнее чем обычный VPS.

С точки зрения клиента, грубо говоря масштабирование очень гибко и прозрачно, и потенциально не ограничено.

на С++ можно только бэкенд.
В особо запущенных случаях, вы можете на С++ написать собственное расширение к apache/nginx, но это крайне редкие вещи.
Ассемблер можно подучить до уровня junior-а, просто чтобы понимать как работает комп, и в artmoney могли бы локальную игрушку взломать. Но это чисто для расширения кругозора.

1. Если в ТЗ было указано на чем делать сайт, то надо было делать на том, на чем указано.
2. Заказчик в таких простых заказах, часто не шарит настолько, что не знает что именно ему нужно. Поэтому у тебя может просто не получиться ему объяснить что не так, и кто виноват.
3. Поздравляю с личным опытом общения с заказчиками. Этот опыт используй мудро, и в будущих заказах старайся предусмотреть развитие странных ситуаций.

То есть тебя не должен волновать вопрос кто виноват, тебя должен волновать вопрос что делать и как предусмотреть максимально возможное количество нестандартных ситуаций. С опытом и репутацией, начинаешь выбирать себе заказчиков, с которыми удобнее работать. В начале пути из-за конкуренции это сложно, так что не принимай близко к сердцу. А Сеошник - недоучка, любой сайт можно продвинуть. Ругать его особо не нужно, но если есть желание, можешь написать длинное пояснительное письмо заказчику, без попыток дальнейшего спора, в котором пояснить что произошло.