I don't have a documentation reference but the optimizer appears to default to deferred mode when the #table and follow-on DML operation are in the same batch (ie, optimizer makes a 'safe' guess during optimization based on limited details of #table schema).
You can get the queries to operate in direct mode by forcing the optimizer to (re)compile the UPDATEs after the #tables have been created, eg:
- create #table outside of proc; during proc creation/execution the #tables already exist so optimizer can choose direct mode
- perform UPDATEs within exec() construct; exec() calls are processed within a separate/subordinate context, ie, #table is know at time exec() call is compiled so direct mode can be chosen; obvious downside is the overhead for the exec() call and associated compilation phase ... which may be an improvement over a) executing UPDATE in deferred mode and/or b) recompiling the proc (see next bullet), ymmv
- induce a schema change to the #table so proc is recompiled (with #table details known during the recompile) thus allowing use of direct mode; while adding/dropping indexes/constraints/columns will suffice these also add extra processing overhead; I'd suggest a fairly benign schema change that also has little/no effect on table (eg, alter table #test replace fiId default null); obvious downside to this approach is the forced recompilation of the stored proc, which could add considerably to proc run times depending on volume/complexity of queries in the rest of the proc