There are a few nuances that may complicate the implementation of this feature.
1. What event should be used to update the displayed data? If by the fact of their change, then in Windows to track such a change must be set PAGE_GUARD displayed page, which is not applicable to all addresses. For example, the memory by which KUSER_SHARED_DATA is displayed will not allow to do it. There is a mechanism of HardwareBreakpoint via DR registers, but it is not fully implemented in FpDebug, and it has too small window for tracking (4 addresses up to 8 bytes long in 64 bits per thread), besides it is only for Intel architecture. This leaves only timer-based or separate button-based.
2. Memory validation by calling TDbgProcess.MaskBreakpointsInReadData. This call is not thread-safe and must be executed through TThreadWorker, which can lead to DeadLock when called from the main IDE thread while the debugging thread is running.
3. In Windows, calling ReadProcessMemory from any thread, even the main IDE thread, is really enough to read memory, but in Linux, reading is done via ptrace/process_vm_readv, which require a call from the debuger-thread, which again can lead to DeadLock. So in this case the only way is to read directly from /proc/PID/mem