When you discover that some functionality is missing or incomplete, it's time for a conversation. The team, including the Product Owner/Customer must get together to determine what to do next. Again, spend some time to use the process of breaking that functionality up into thin slices. This discussion can occur at any time and doesn't have to be restricted to specific meetings like Scrum's backlog grooming or sprint planning. It can be held anytime that the team is able to have the discussion.
If the discovered functionality is important enough, the business people will ask that the stories are moved forward to be completed sooner. The trade-off is that other stories are pushed back and will be completed later. By having paper thin stories and a measure of the number of stories the team is completing over some period of time, it's much easier for the business people to make these decisions.
For example, the conversation may go something like this:
Note as well that it may also be the case that the business people may decide to delay the release until all those stories are ready to be shipped. Also, you should note the collaborative nature of this conversation. While the specifics of the example conversation are somewhat contrived, I've been present with many teams that have worked this way. This approach is far superior to having the Product Owner go away and return at some point later with a handful of stories. Story writing is a team sport!
In any case, using this approach enables these sorts of business decisions. This is the primary reason to work in such small slices, and was the whole intent of the Story approach from Extreme Programming in the 1990's.
After all, the ability to adjust to and accommodate these changes is part of the definition of agility.