Currently when a view is defined with Inserts, Updates and Deletes with Instead of Triggers with "FOR EACH" row processing, the change set (the rows that are changing for the statement) typically is like

loop on (select ids from (view) where predicate) 
begin 
    procedure body 
end 

where there is a possibility that "procedure body" will change underlying tables such that the "loop on" query results could vary during the processing. Like concurrent updates. This could be avoided by materializing the ids in #temp table before processing any of the rows.