Why would adding a column to a view corrupted a table-valued function?
Yes, this is expected. Functions and views that use SELECT * end up storing part of the metadata themselves relating to the underlying columns, so it is very easy for them to get confused. I talk about this problem in the following post from 2009:


Bad habits to kick : using SELECT * / omitting the column list


And also in my recent GroupBy presentation:


T-SQL : Bad Habits and Best Practices


How do you avoid this problem?


Don't use SELECT * in objects.
Make your functions and views WITH SCHEMABINDING, which means you can't modify the underlying objects without also modifying the objects that reference them (this also has the side effect of prevent * so win-win).
In this specific case, you can fix the object so that Bar returns the correct data by using:

EXEC sys.sp_refreshsqlmodule @name = N'dbo.myTVP';



Incidentally, the documentation for sys.sp_refreshsqlmodule describes this exact scenario:


  Updates the metadata for the specified non-schema-bound stored procedure, user-defined function, view, DML trigger, database-level DDL trigger, or server-level DDL trigger in the current database. Persistent metadata for these objects, such as data types of parameters, can become outdated because of changes to their underlying objects.


As an aside, you should never use FROM myTVP() but instead always specify the schema, e.g. FROM dbo.myTVP(). I talk about that in an old post, too.