Интуитивно (ибо не программист) не согласен. Это, скорее, инфраструктурная вещь. Ну, вот как возможность передачи темпа из DAW в плагин, которому это нужно, сделана на уровне формата, так должно быть и здесь.
Например, переделать какую-нибудь струнную библиотеку и плейер, её проигрывающий, чтобы появилась возможность передачи информации о задержках в сэмплах (разных для разных штрихов), и чтобы появилась возможность передавать информацию о будущих midi-событиях (пакетом, а не в реальном времени) — адова работа. И если будет только одна-единственная DAW, которая это умеет в проприетарном формате/алгоритме, и только пара плагинов — никто за этим не пойдёт. Ну, или пойдут кто в лес, кто по дрова.
Для таких инфраструктурных начинаний нужно создавать рабочую группу из представителей ведущих разработчиков, которая несколько лет (быстро это не делается) будет изучать вопрос, проигрывать все возможные сценарии использования новой технологии, определять все параметры, и потом только создадут стандарт. Оркестровым библиотекам нужно сколько «будущего времени»? 5 секунд? 15? А завтра появится какой-нибудь рэп 2.0, и они запросят несколько минут «на предсказание». Или другой вопрос: только ноты должны передаваться? Или то, что внутри нот (VST3 и MIDI 2.0)? А кривая изменения темпа должна передаваться?
Именно такими рабочими группами создаются форматы MIDI 2.0 (очень неспешно) и MusicXML. В разработке последнего формата основную роль играют дядька из Finale (программа, практически потерявшая рынок) и дядька из Дорико. (Разумеется, там есть и другие дядьки, вход открыт для всех.) Собирают они, к примеру, все случаи использования знака арпеджиато с времен очаковских и до наших дней, определяют параметры, которые будут необходимы и достаточны, чтобы ноты с этим знаком не теряли корректности графического представления при обмене файлами между приложениями, и вносят это в формат. А остальные производители нотных редакторов подтягиваются — подтягивают свои внутренние алгоритмы импорта и экспорта MusicXML.
Так это работает, имхо.