Investigate removal of enable-proposed-api command line argument

[jrieken]

Follow-up from #110617 and countless related discussions.

Today, proposed API can be used by extensions when

1. running out of sources
2. when an extension is built into vscode (./extensions-folder)
3. when developing an extension
4. when adding an extension to the allow list in product.json
5. when using the --enable-proposed-api <extension-id>

The primary goal is to remove option 2 and 5. A stretch goal is to have a process for how to onboard extensions to be in the product.json allow list.

[jrieken]

To shed some light on the "why".

We have added proposed API for two reasons

1. get feedback from extension author while working on an API
2. take out pressure to finish API work within one iteration

The latter works well for us and vscode.proposed.d.ts has become the place in which API development happens. The former doesn't work very well. We get very little feedback on API and I don't want to blame anyone for that. For an extension author the function of an API is important and they are happy when it does its job. An API being consistent with other APIs and in-line with our guidelines is usually a non-goal or of little interest. However, requests for allowing to consume proposed API more freely is a constant distractor and something that doesn't align with our API process. These requests originate from the "feature" of freely allowing anyone to use proposed API via a command line flag and that must be reconsidered

[gjsjohnmurray]

We get very little feedback on API

When extension developers who have tested a proposed API and are happy with it, but the sponsor isn't but doesn't say why not, what's to be done?

#59921 (comment)

[jrieken]

but the sponsor isn't but doesn't say why not, what's to be done?

For that specific case I have no good answer and I do share the frustration

[jrieken]

This will not happen