Конечно, fill, line и подобные базовые функции можно и не переписывать (это только форт-процессору нужно будет написать с нуля). Вопрос в другом - очень уж неопределенная ситуация с GUI в мире МК, много полуфабрикатов, метаний от одного популярного проекта к другому. Та же LVGL прошла целой серией для модулей на ESP32... вопрос в том, что со сменой версий все это перестало собираться. В то же время от МК надо не так и много - кнопку, списки с выбором, график, индикатор наподобие progress bar или небольшого значка со шкалой заполнения. И тогда можно будет Форт для МК "вывернуть наизнанку", а точнее - привести в приемлемое состояние, чтобы введение Форта в систему не обрушивало функциональность до нуля, заставляя переписать все. Тут нужно найти баланс между готовыми библиотеками, работающими с аппаратурой, и необязательными дополнениями, которые сбивают с толку и затрудняют разработку. Если в качестве основной идеи принять "Forth == glueware", многое встает на место - можно пользоваться базовыми библиотеками, не стремясь их обязательно переписать "чтобы было все на стеке", а отсутствующее или неудобное оформляется на Форте.

А не будет ли это всё медленно и печально? Может всё-таки fill(x1, y1, x2, y2,color)?
И прозрачность тоже не мешало бы иметь, т.е. цвет в формате RGBA.

Интересная (судя до демо-примерам) библиотека LVGL для Arduino отличается достаточно быстрой изменяемостью, вплоть до потери совместимости с предыдущими версиями. Отсюда возникла идея, в чем-то противоположная Форту с GUI на ПК - вместо того, чтобы управлять готовыми виджетами из библиотеки, можно (все-таки!) переписать базовые виджеты, имея в распоряжении только pixel(x, y, color). В принципе, линии, прямоугольники, эллипсы и подобные базовые примитивы, которые поддержаны чем-то простым, можно использовать, но общая идея в том, чтобы все-таки "выстроить" GUI для Arduino и подобных платформ от самых базовых основ.