Изменение тэга это например поворот на 90 градусов (смена ориентации).

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

mayton/photos/{YYYY}/{MM}/{DD}/{model}_{YYYY}{MM}{DD}_{width}x{height}.jpeg
Сомнительный шаблон.
Зачем в имени файла размерность изображения?
Почему модель вынесена в начало (сортировка будет по модели)?
Почему нет времени или счетчика? Или в течение дня будет только одна фотография?

Я бы советовал использовать мой шаблон, в нем ничего лишнего и он выверен практикой.
Единственное, что я не указал — если одно и то же событие снималось разными фотографами, то в каталоге альбома я создаю подкаталоги на каждого фотографа и уже внутри них идет "{ymd}{hm}_{####}_{crc32} [{tag}] ({device} {model})".
Для фотографий важно упорядочивание по хронологии, поэтому дата или счетчик должны быть в начале файла. Модель фотоаппарата является чисто информационным атрибутом, поэтому должна быть в конце или вообще не указываться. Я указываю, потому что по модели можно понять, что следует ожидать на фотографии (какое качество и особенности).

Что касается даты/времени, то нужно учитывать следующее.
Во-первых, в EXIF есть несколько тэгов для этого: Date/Time, DateOriginal/TimeOriginal, DateDigitized/TimeDigitized, DateTimeStr (это не считая проприетарных и нестандартных полей). И разные вендоры по разному понимают, что и в какие поля нужно записывать.
Во-вторых, кто-то пишет в эти поля локальное время, а кто-то UTC. Кто-то учитывает сдвиг часового пояса, кто-то нет (в зависимости от свежести ПО).
В-третьих, возможны ситуации, когда дата/время в EXIF не совпадает с датой/временем в атрибутах файла (например на устройстве часы выставлены неточно, но имеется GPS, а в EXIF записывается время со спутника).
И для этих моментов нет общего решения. Нужно или принять для себя какой-то общий принцип (например определить приоритеты полей), или для каждой модели обрабатывать данные индивидуально.

И еще, метаданные есть не только в EXIF.
Есть IPTC, есть расширения JPEG, есть форматы tiff/tga.

А нужен ли в линуксах скомпилированный файл?
Там по-моему java-машина есть всегда.

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

И как я вижу, CRC в имени файла отсутствует.
Я все же советую его добавить.
Файлы в течение долгого времени могут незначительно модифицироваться, причем изменяться может даже не содержимое, а метаинформация (например тэг ориентации). CRC позволит искать оригиналы/дубликаты, не проводя анализ и распознавание образов, это будет просто на порядки быстрее и проще.

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

Если имя файла будет состоять только из счетчика или таймштампа, то оригинал по имени файла не найти, поскольку такое имя будет неуникально.
А вот если в имени файла будет присутствовать CRC, то он конечно не гарантирует отсутствие коллизий, но на практике коллизии крайне редки и он почти гарантировано будет уникальным.
А с именами файлов работать намного проще, чем с парсерами изображений — хоть в Total Commander (Multi-Rename Tool, поддерживает регулярные выражения), хоть в множестве готовых утилит по массовому переименованию файлов, хоть сохранив имена файлов в текстовый файл.

Например в Total Commander есть два таких крайне полезных инструмента, как мультипереименование и поиск дубликатов.
И оба поддерживают файловые плагины, в том числе такие полезные, как exif (тэги EXIF) и wdhash (разные хеши, в том числе CRC32).
При поиске дубликатов я просто сравниваю CRC в имени файла с рассчитанным CRC — и все изменения/дубли/оригиналы как на ладони.

У меня сценарий бэкапов следующий.

Время от времени я скидываю фотографии с источников (смартфон, фотоаппарат) на диск.
Затем делаю массовое переименование по шаблону "{album, location, event}/{ymd}{hm}_{crc32} [{tag}] ({device} {model})".
Затем ищу дубли между обработанным каталогом (с новыми фотографиями) и основным каталогом (с бэкапом).
Дубли в новом каталоге убираю, а оставшиеся фотографии перемещаю в основной каталог с бэкапами.

Я выбрал CRC, а не MD5, потому что он слишком длинный и сложно считается.
Если помещать его в начало имени файла, то остаток (с датой, временем и прочим) не будет виден, да и сортировка слетит.
Если помещать его в конец имени файла, то остаток не будет виден и визуально его будет не сравнить.