dom1n1k

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

На мой взгляд, танковые щели 21:9 имеют преимущество только при работе со специфичными, очень широкими данными. Большие таблицы, графики - что-то типа биржевых котировок, диаграмм Гантта и тому подобное.
Для веб-дизайна - хрень.

P.S. Вот еще в соседнем ответе очень хороший пример привели - аудио/видео-редакторы с их монтажными дорожками. Одним словом, если контент стремится в ширину.

Всё абсолютно так же - собственные/вымышленные проекты.
Даже если они не будут реализованы и так и останутся в виде картинок - это всё равно намного лучше, чем ничего.
Если приходит новичок и показывает пару прототипов и макетов - о нём можно сделать какие-то выводы, есть какой-то предмет для разговора.
Если он не показывает вообще ничего - о чем с ним можно говорить?

Привлекает project management, но можно ли им стать без опыта работы программистом?

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

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

Если тупо центральные точки, а не все границы, то по-моему быстрее самому по карте натыкать, чем ходить вопросы задавать :)

HTML/CSS-верстка тут практически непригодна.
Нужно использовать какую-то графическую библиотеку, работающую с графикой как с логическими примитивами (то есть не только рисует, но потом умеет двигать, обрабатывать действия пользователя и пр.). Это может быть и SVG, и canvas - кому что привычнее и удобнее. В качестве примеров можно привести Snap.svg и Paper.js соответственно, но не обязательно их, есть и другие альтернативы.

Я предпочитаю группировать стили по смыслу и по отношению к одному блоку, а не по отношению к размеру экрана.
Разделять размеры по файлам и тем более папкам кажется логичным только на первый взгляд. По факту так делают жертвы формализма в ущерб здравому смыслу.
Ну вот открыл я один из файлов, смотрю на код блока. Как я должен догадываться, как он себя поведет при уменьшении экрана? Лезть в другой файл? А потом в третий, четвертый... А может там и нет ничего - я не знаю заранее. А ещё часть стилей всегда общая для разных размеров - их тоже в отдельный файл?

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

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

P.S. Хотя я иногда завидую таким людям - мне бы такой оптимизм.

в фотошопе если измерить от нижнего края Блока А до верхнего края Блока Б

Измерять нужно не от края букв, а между базовыми линиями. От б/л последней строки предыдущего блока до б/л первой строки следующего. Потом вычитаешь высоту одной строки (font-size * line-height) и получается величина отступа между абзацами.

А зачем родительскому блоку говорить flex?

Правильный ответ:

<ul>
    <li><a href="#">Что-то</a></li>
</ul>

li > a {
    display: block;
}

Конечно, в реальном коде стили лучше вешать не на теги, а на классы. Тут просто принцип.

СС-фотостоков довольно много, но самый известный и популярный unsplash.com

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

В качестве далеко не идеального, но очень простого костыля:

#map {
    max-height: 90vh;
}

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

Уголок тут не играет никакой ни смысловой, ни эстетической роли, которые оправдывали бы его присутствие. Это просто потуга дизайнера в духе "чтобы тут ещё всунуть, чтоб они не подумали, что я мало поработал? ну хз, вот пусть ещё уголок будет!"

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

Масштаб увеличенный у клиента настроен.
Это кстати вполне нормальное явление и не должно ломать верстку.