dom1n1k

Мне кажется, чем-то жертвовать всё-таки придется.
Глобально вариантов два: либо верстать настоящей таблицей (но тогда бордер придется рисовать кусочками через JS), либо таблица верстается столбцами (обходимся чистым CSS, но есть опасность разъезжания, если где-то будет много текста).
Думаю, лучше всё-таки сделать на JS, хотя я и сам стараюсь обходиться без него по возможности.

Не в поддержке проблема, а в недостатке гибкости Бутстрапа.
Если UI более-менее сложный, лейаут (да и сами блоки) могут серьезно меняться на разных разрешениях, а не только прыгать между режимами "в ряд" и "стопкой".
Очень показательный пример, который я уже приводил неоднократно:
https://www.smashingmagazine.com/
Обратите внимание на поведение менюшек, шапки, поиска. Попробуйте сверстать это на Бутстрапе. Не, я вполне верю, что при должном упорстве это рано или поздно получится. Но в конце вы неизбежно зададите себе вопрос - а нахрена он был мне тут нужен, какой профит я с него поимел?

Если вы хотите проверять именно поддержку свойства, то думается, что полностью надежного способа нет. Во всяком случае, мне он неизвестен.
С режимами наложения там всё непросто, некоторые браузеры поддерживают частично, плюс они по разному могут работать для HTML/SVG элементов.
Supports на текущий момент фактически не работает, потому что его не все поддерживают.
Нужно тестировать именно тот кейс, который нужен конкретно для задачи, очерчивать круг браузеров и проверять потом браузер.
Да, не очень это удобно, но другого способа я не знаю.

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

Никак. Базовая линия плавает в разных браузерах и осях.
Если принципиально нужно выровнять всё до пикселя с абсолютной кроссбраузерностью, то единственный выход - сделать кнопку картинкой.

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

Как верно сверстать такую карточку товара?
codepen.io/dom1n1k/pen/gwOQYd

Попробуй инпуту и кнопке принудительно указать одинаковый шрифт (или просто обоим inherit). По дефолту он не равен шрифту у body.
Теоретически, разный шрифт и разная высота базовой линии могут раздвигать.
Кроме того, я бы отделил подпись "введите номер телефона" в отдельный блок, чтобы она не мешала своей базовой линией.

Практически никак. То есть какие-то отдельные проблемы решить можно (запретить зум мета-тегом, запретить все лишние скроллы), но в целом все равно ощущения цельного, нативного приложения не будет. Обязательно будет что-то съезжать, ворох анимаций будет тормозить... Будет суррогат ни рыба ни мясо.

Вадим Макеев рассказывал, что на новых Андроидах есть возможность открывать сайты в полноэкранном режиме, без браузерной шапки. Но это вроде бы только в том случае, если пользователь предварительно установил себе ярлык на рабочий стол. При первом заходе (вроде бы) никак. Но сам лично пока не пробовал, могу ошибаться.

Сам проходил Jade и тоже остался им не совсем доволен. Были плюсы, но были и минусы и в целом выходило не лучше, а просто как-то по-другому. Тоже смотрел на альтернативы, и они нравились ещё меньше.
Twig и ему подобные - кмк, хороши в качестве шаблонизаторов, но не HTML-препроцессора, то есть тоже мимо.
Так что вернулся на голый HTML. Можно опционально добавить Emmet, но у меня как-то не пошёл он.
А потом оказалось, что циклы хорошо реализуются в Angular/React/Vue (подчеркнуть нужное по вкусу), так что прикручивать ещё и препроцессор стало вообще лишним.

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

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

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

Например, если выбрать в карточке сотрудника пол "мужской", то полю "дата последнего гинекологического осмотра" я бы поставил атрибут disabled.

Даже не знаю, как еще объяснить, по-моему всё предельно очевидно.

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

"Идеального" способа, к сожалению, нет.
Все варианты либо костыльны и некрасивы с точки зрения кода (например, нашлепывать сверху белый треугольник), либо не совсем кроссбраузерны (отсечение по SVG-маске), либо геморны для контент-менеджера (готовить картиники с уже обрезанным углом).

C нормальными нормальными телефонами и бразуерами проблемы нет, потому что логическое css-разрешение экрана != физическому разрешению жк-матрицы. При вёрстке нужно ориентироваться на первое. Ну и, конечно, указывать мета-тэг вьюпорта.
mydevice.io/devices

Хотя мне встречался китаец, у которого логическое разрешение в браузере было равно физическому и потому всё было очень мелко. Но таким ничего не поможет. Да и было это довольно давно, года 3-4 назад.