I generally agree, but in reality it means that instead of one database delete statement we will issue two each time we delete an instance. And in 99% of cases the second statement will be a waste. So I think we should rather leave it as it is, maybe just log a warning instead of error.
Or maybe just simply ignore the case : when an entity is referenced in sys_fts_queue but not in database anymore, the only possible reason is a delete, which is not an abnormal state. Then, indexing does not make sense anymore, and could simply pass over. Like ignoring an exception on a stream.close() in a finally.
If one is skittish about not reporting the case, I agree, a warning would be enough. This way applications that do lots of delete can set the log level to error in order to avoid log cluttering. Currently, only OFF is possible which is not wishable.
Is it possible to plan at some point to have this issue reported as a warning instead of error ? We keep having long list of messages while testing and switching the log to OFF is not really a solution.