For those who don't have that reference handy, the Wikipedia article on ANSI-SPARC provides a decent overview.
How does the logical schema handle input (columns) from applications for which it is not defined in the logical schema?
The short answer is that the logical schema can't handle (store) input if it doesn't have columns defined for it.
The long answer is that I think the problem is that you've got the frame of reference backwards.
The internal or logical schema needs to have a representation for all of the data that all of the applications (external schemas) may present. But the external schemas don't need to know of all of the potentialities that are possible within the logical schema.
What that quote is focusing on is adding a new, external view onto the existing database. That will likely require the logical schema to be extended to handle the new bits of data that the new view will require. But the changes required for this new external view will have zero bearing upon the existing external views and their perception of what the database schema looks like.
To use a concrete example...
Say I have an application that tracks ticket sales. I have all sorts of wonderful schemas built around pricing, history, seating, sellers, and buyers. So my ticket sales app has a view of what it perceives the database schema to be.
Later on, I'm talking with another business partner and realize that with a little modification to the database and a new external view, I can easily track auction results. The premise of that quote is that I should be able to make changes to the logical schema (my database) to support my new auction results application without having to make any changes to my ticket sales tracking application.