Good overview of the Touch Bar and its developer API by Benjamin Mayo:
Developers can display pretty much whatever they want whilst their app is in the foreground; this includes swapping out views and buttons depending on the current window of their app (a compose window necessitates different Touch Bar accessory views than the inbox window). However, the Touch Bar does not allow persistent widgets, status items or similar features like always-visible news tickers. These constraints are unlikely to be lifted either; Apple is imposing the restriction so that the UI under the user’s finger isn’t constantly changing due to spurious notifications or text messages.
Apple wants the bar to display peaceful relatively-static UI based on the current task. Major changes to the Bar should only happen when the application state drastically changes, such as opening a new tab or beginning a new modal activity. To repeat: once an app’s window is not active, it loses its control to influence what is shown on the Bar. The system Control Strip sits to the right in a collapsed state by default, but can be disabled entirely in System Preferences if desired.
This makes sense to me: the Touch Bar is intended to be an extension of the keyboard that deals with input – it’s not a smaller Dashboard or a widget container. This means that apps like PCalc won’t be able to persistently display their controls in the Touch Bar unless they’re the frontmost (active) app.
The more I think about it, the more the Touch Bar feels like the natural evolution of QuickType and the Shortcut Bar from iOS – to the point where I wonder if we’ll ever get this kind of evolution on the iPad Pro as well (where the current app is always the frontmost one and system controls could use a faster way to be engaged than Control Center). Perhaps with a new external keyboard with its own embedded Touch Bar and T1 chip?