Hello! 
From an engineering perspective, designing a plugin system in a web context is no simple task, especially if youāre aiming to ensure security. Itās a topic that many companies have delved into deeply. If youāre inclined to explore it, I recommend this Figma article:
The crux of the issue is this paradox:
[ā¦] we wanted to make sure plugins would be safe for users to run, so we knew we wouldnāt want to simply
eval(PLUGIN_CODE). That is the quintessential definition of insecure! Yet, eval is essentially what running a plugin boils down to.
The TLDR is: currently, the best solution for permitting unsecured third-party code for network requests or creating some UI is to use iframes in conjunction with a postMessage() messaging system.
But iframe is a solution that comes with a staggering number of limitations.
Once weāve come to terms with the fact that we ā or anyone else operating in āuserlandā ā canāt do anything about these limitations, what we can do is aim to provide an SDK that allows for an āacceptableā level of convenience to execute common operations.
Now, talking about the more concrete problems 
If the autosizer is not functioning, this is a bug and we need to fix it (btw, DONE!). However, we cannot allow a dropdown to ābreak outā from the iframe. It would be nice, but itās simply not possibile.
This means that any select/dropdown with an overlay will always look horrendous if used in a field extension 
The component we provide is more suitable for other hooks, like custom pages, custom sidebars, where the vertical space is not so limited.
This doesnāt imply that one cannot contemplate introducing new hooks if this scenario is common! For instance, something that allows plugins to associate multiple actions with a field via a single ānativeā dropdown could be very easy to implement:
About field extensions
[ā¦] iframes sometimes arenāt rendered at all (like if the field is hidden or in a collapsed fieldset)
The iframes related to the fields are not renderedā¦ when the field itself is not rendered. If a fieldset is collapsed, and its internal fields are not visible, why should we render the plugins related to those fields? Their job is to extend the fieldā¦ but the field is not there! I wouldnāt consider it a bug, but rather a consequence of the purpose for which field extensions were designed.
I feel similarly about the idea of supporting the concept of āhidden fieldsā (that is, present but invisible). What would be the purpose? It seems to me a workaround to have some custom code somehow linked to a field, even when the field itself is not present. If this is the need, field extensions are not the appropriate tool.
We should also always take into account the potential large-scale issues that certain decisions may cause. Some clients have hundreds or thousands of fields within a single record, and removing every field when you collapse a fieldset can also help to decrease the sluggishness.
If you want to manage the form in its entirety (ie. coordinate multiple fields), there are other hooks available, like the suggested form outlets. Are existing hooks inconvenient/unfeasible? Again, letās define the specific use cases, and we can evaluate whether to extend their functionalities, or to introduce completely new ones!
To wrap upā¦
Certainly, I havenāt been exhaustive in covering all the topics discussed in the threadā¦ but I was more interested in conveying the general philosophy and approach we used in designing our SDK, so
as to better guide future requests in a way that makes them more easily actionable.
Thereās no need to burden existing hooks with more responsibilities than they already have. Letās try to define what would be nice to have, and we can find/introduce clean and specific ways to get there (if the iframes allow us, of course!)
Sometimes, the cleanest solution to a problem may not necessarily involve the concept of plugins, but rather exploit other tools that we provide, such as webhooks.