You could also move some checking time to the users machine. At the time
the documentation is rendered, the commands in ++E are executed and
compared internally with the ++R stuff.
Since execution might take some time, first show the ++R output and
spawn a background process that compares the output of ++E with ++R.
If that is equal, everything is fine. If it is different. That is a bug.
So notify the user with all the information (about his system) that s/he
should send to a bugtracker.
This could potentially introduce a lot of overhead into the execution
of the )display operation command. The "map" function, for instance,
has about 80 instances which would introduce 80 background executions.
If we could do that in parallel (since each test is independent) this
might make sense on a multicore machine. But we can certainly test at
build time.