I was just doing a Smart Rename, renaming column "isactive" to "stati" in tbl_orgz. All dependent views and procs were handled correctly. However, the very last alter generated was an alter trigger on an "instead of insert" trigger on tbl_student: smart rename was wanting to swap out column isactive (which exists) for stati (which doesn't exist) on the SELECT <columns> FROM INSERTED. I have no idea how it thought this was related to my change, since this is a trigger on a different table. The tables are related by a FK, but the trigger itself doesn't involve the table I was changing. I think it would have failed if I had not caught it (since the new column name would not have existed), though actually... it might have completed the ALTER successfully and failed at runtime - this was a live db so I wasn't going to try it
I guess since an INSTEAD OF INSERT trigger could potentially be used to do a multi-table related insert with one insert command, and the table I was changing was involved in an FK insert, Smart Rename though that the isactive column from the INSERTED alias could be the same as the column I was changing - kind of jumping to an incorrect conclusion in this case.