но ведь то, что сделано, было чем то обусловлено ?
текущая реализация не удовлетворяет поставленным требованиям или требования изменились ?

Все же я не понял что было задумано ранее и что хочет юзер сейчас :
1. можно иметь 2 одинаковых ключа ?
2. можно иметь 2 близких ключа ?
может чуть рассказать что это за данные ?

Ну и понятно, что между 1й и второй можно позволять менять существующий ключ его перезаписывая (в тч с заданной точностью)

Ну как всегда - стоит чуть "углубиться в детали", и интерес к обсуждению утерян. Видимо появляются соображения типаЧто в общем разумно - хотя не думаю что факт "кадр имеет продолжительность" оказался чем-то новым и/или сложным.

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

В общем, сомневаюсь. Свежие мысли/соображения были бы очень к месту

Так я и не скрываю что речь идет чисто о постановке.

Ну вот совершенно не понимаю откуда Вы это все взяли? Разве я это говорил - или хотя бы намекал? Да нет же

Пара (время(ключ) + значение) известна как KeyFrame, это достаточно популярный термин. Это "аналитическая" форма данных кривой, которая работает для любого FPS. Для любого времени t (double) кривая выдает значение. Откуда взялось это t - дело того кто эту кривую пользует. Ограничения - точки кривой должны находиться друг от друга на расстоянии (времени) друг от друга  не больше заданного, конкретно 1.0e-6.

Да, юзер часто работает "по кадрам", но никаких конверсий/преобразований аналитической кривой не происходит. Просто юзер видит/имеет табличку с числами (1 ячейка = 1 кадр), а не кривую в виде графика. Конечно числа в табличке = интерполированные значения кривой

Вот собсно и все. Неужели это так сложно, непостижимо? Какое-то у Вас мЫшление... ну, в общем, у меня точно не такое 

Переключился с 30 fps на 60. Кол-во колонок в табличка кадров стало вдвое больше (продолжительность кадра уменьшилась вдвое). Данные каждого кадра пересчитались из той же анимационной кривой с др шагом по времени, но сама кривая никак не изменилась
"В огороде бузина, в Киеве дядька". Конечно может менять и саму кривую, она не "одна на всю жизнь". Но это происходит в др окнах/редакторах. Разумеется изменение кривой вызывает пересчет всех покадровых данных

Проблемной является ситуация когда 2 и более ключей кривой оказываются в одном кадре.

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

Также понятно что дискретное представление по кадрам имеет гораздо меньшую точность. Для double аналитической кривой достаточно чтобы расстояние между точками по времени не превышало 1.0e-6,  а это на неск порядков меньше разумного времени кадра. Т.е. при желании юзер может создать затейливую анимацию в рамках всего одного кадра, но обычно в этом нет смысла, т.к. анимация проигрывается по кадрам.

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

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

Юзера беспокоит/напрягает "скрытая" анимация (в рамках одного кадра) которая может возникать по многим причинам. Просто ее запретить - нельзя. Суетиться с бесконечными предупреждениями - и самому накладно и юзера задолбает. Нужно какое-то разумное, гибкое поведение. Какое?