Thanks for your bug report, I agree. This aspect of the table is quite confusing and I will revise it… possibly by adding a third set of columns for ‘internal’ for those APIs (not just reset() - there are others) which affect only the internal model and do not update either front-door or back-door accesses. The intent of the table was to show where the different APIs could be applied: at field or reg or block level.
Note: although reset() does not affect the DUT, a subsequent call to update() (with either UVM_FRONTDOOR or UVM_BACKDOOR access specified) would then propagate the reset() outcome to the DUT.