This is very specific to your example, but I guess my point is it is almost always possible to design your in-progress state in a way such that new features are obscured.
Consider, however, cases where the company has long term relationships with customers; say, industries where real customer support is in place. In these cases, an infrastructure for “feature toggles” is extremely helpful, because you can turn on the feature for specific customers (or developers for testing!), or certain segments of customers (e.g. early access customers). In such an infrastructure, there is no “security through obscurity”; you’re authorizing transactions on the backend (based on whether specific users are allowed to use the feature), and merely enabling the UI on the front end based on user whitelists.
Incidentally, once this is in place it’s just another half step to implement phased releases, or A/B testing. Makes rolling back easy too.
It's not about delivering changes that are not fully ready to be in production. It's about breaking down a larger change, and delivering it in chunks, as and when each one is fully ready.
If it's a requirement that such features absolutely cannot be invoke by end users in advance of release, it seems like you could always use access control or feature toggles in front of the new backend API. It's important to be aware of such a requirement, but I don't think the fact that some use cases have this requirement gets in the way of "Keystone Interface" as a concept.
Say you are adding new features those might be exposed in a API prior to have the UI components that facilitate the user interaction directly this isn’t enough to prevent the user from accessing them if there are no additional controls on the backend.
Even worse I would bet good money that for web applications many teams would add UI components and use the “hidden” attribute as a keystone and even if they don’t add any direct UI elements they quite likely to add the JavaScript functions that facilitate those before exposing their trigger in the UI.
Let’s say a user notices that submit order POST requests now have another field “rush_order=false” what happens when it’s set to true?
Sure you can say well the businesses logic would handle this but then you need to make your business logic “aware” of this type of a development which means the keystone isn’t the UI anymore.
This type of development can expose you to various business, legal and security risks if there aren’t excellent controls behind it.