Vindicar

:0: RuntimeWarning: coroutine 'Application.shutdown' was never awaited
:0: RuntimeWarning: coroutine 'Application.initialize' was never awaited

Ты вызываешь указанные функции как обычные (Application.initialize()), а это корутины. Их так вызывать бесполезно. Если ты их вызываешь внутри другой корутины (async def функции), то можешь исправить вызов на await Application.initialize(). Если же ты пытаешься вызвать их из обычной функции (просто def), то все становится куда сложнее...

try: 
    loop.create_task(exc())
except ZeroDivisionError as ex:
    print(f"Ошибка {ex} обработана")

1. Ты создаёшь задачу на базе корутины exc(). Созданная задача не выполнится немедленно, а только встанет в очередь исполнения (хотя в питоне 3.12 это поведение можно изменить, но по умолчанию это так). При этом с корутиной ассоциируется future-объект, который находится в состоянии "ожидание", так как корутина ещё не завершила работу.
2. Ты проверяешь, не возникло ли исключение в процессе создания задачи. Это может произойти, только если exc() - не корутина. В остальных случаях операция будет успешна независимо от содержания exc(), так как см. пункт 1.
3. Ты вызываешь loop.run_forever(). Рабочий цикл (loop) смотрит в очередь исполнения, и видит в нём только корутину exc(). Она получает управление.
4. Корутина exc() выбрасывает исключение, но не ловит его. Ассоциированный с корутиной future-объект переходит из состояния "ожидание" в состояние "отказ", и сохраняет информацию об исключении. exc() завершает работу.
5. Рабочий цикл проверяет, кто хранит ссылку на task - и понимает, что никто. Как следствие, даже в будущем никто не сможет узнать, что корутина выкинула исключение. Поскольку рабочий цикл - штука типовая, он понятия не имеет, что делала наша корутина и как надо реагировать на исключение в ней. А потому единственный вариант для него - написать в журнал работы о непойманном исключении и надеяться, что программист это увидит и поправит.

task = asyncio.create_task(exc())
try:
    # await asyncio.gather(task)  # <- gather() не нужно, если у тебя одна задача
    await task
except ZeroDivisionError as ex:
    print(f"Ошибка {ex} обработана")

1. Ты создаёшь задачу (успешно), а потом с помощью await-вызова просишь дождаться её завершения и получить результат.
2. Корутина main() приостанавливает своё выполнение и сохраняет свой контекст, а также встаёт в очередь, ожидая, когда сработает future-объект, связанный с task.
3. Рабочий цикл (loop) asyncio смотрит в очередь выполнения и видит, что корутина exc() готова выполняться (она не находится в await вызове, а только начала работу).
4. Корутина exc() получает управление, выполняется, и генерирует исключение, которое не поймано внутри этой корутины. Future-объект, связанный с этой корутиной, переходит из состояния "ожидание" в состояние "отказ", и сохраняет информацию об исключении. Корутина exc() завершает выполнение. При этом о её future-объекте знает корутина main(), поэтому рабочий цикл не дёргается по этому поводу - у main() будет возможность отреагировать на происходящее.
5. Рабочий цикл (loop) смотрит в очередь выполнения и видит, что там только корутина main(), причём она готова выполняться - future-объект, который она ждёт, более не находится в состоянии ожидания.
6. Корутина main() получает управление и восстанавливает свой контекст, продолжая с того места, где она остановилась. Так как future-объект находится в состоянии "отказ", оператор await читает из него информацию об исключении и перевыбрасывает это исключение внутри main().
7. Это исключение обрабатывается блоком try-except в main() как обычно.

Цитата из документации:

Return the currently running Task instance, or None if no task is running.

Как я это понимаю, если ты запланировал выполнение функции как задачи через asyncio.create_task(), то эта функция, и все, вызываемые в ней, смогут получить объект задачи, вызвав asyncio.current_task().
Если же управление в текущую функции было передано без использования задач на любом из уровней, только через await вызовы, то current_task() вернёт None.

Но вообще довольно странно. Эксперимент показывает, что хотя бы одна задача должна быть.

На питоне 3.11 код выводит два объекта задачи, один создаётся run() или run_until_complete(), а другой - create_task(). Тогда получается, что получить None невозможно.

Я вижу два потенциальных источника проблем.
1. Ты говоришь, что библиотека будет дёргать callback при изменении значения свойства. А когда она будет это делать?
Ей ведь нужно выполнить для этого какой-то код, причём наверняка синхронный. Пусть какой-то метод, который проверит очередь событий, извлечёт оттуда новые и дёрнет соответствующие callbak'и. Этот код точно вызывается?
2. Ты делаешь await iface.call_method('bla'). Ты уверен, что обновление свойства произойдёт после завершения await? Если оно произойдёт до, то твой вызов wait_property() не увидит обновлений. Возможно, стоит вешать callback до вызова call_method()?

Читай документацию, там всё есть.
Функция create_task().
Класс Task.
Функция wait_for().

Вообще-то gather() возвращает исключения и результаты в том же порядке, в котором переданы корутины. Всегда.
Но ты сам себе выстрелил в ногу вот этим: *{f1(), f2()}
Ты указал литерал множества, а это не упорядоченная коллекция. Так что в каком порядке были переданы корутины - хз.
Положи их в кортеж или в список перед отдачей в gather(), и проблема уйдёт - элемент выходного списка с индексом i будет соответствовать корутине с индексом i в исходном кортеже/списке.

Разницы нет, в том числе в твоём описании.
Текущая корутина при await-вызове приостанавливается, её состояние сохраняется.
При этом реактор может заниматься другими вещами (в частности, выполнением await-вызова).
Когда await-вызов завершиться, состояние корутины будет восстановлено, и она продолжит выполнение.