I honestly can’t remember all the reasons that we made that decision, as it was made about 4 years ago now and at the time we didn’t document the why of it. I should note that documenting this type of decision is something we’re working to greatly improve with Aurelia vNext.
In general, a lot of decisions were made for reasons of performance and consistency, as well as aligning with some web components callback standards, ES2015 and module loader standards trends. Additionally, because Aurelia is an e2e templating and binding system, not based on KO, it has some different internal structures and capabilities, which again, were designed around performance and other scenarios. During our lengthy year+ alpha and beta period, I don’t recall anyone asking for this to be changed, or finding any issue with it, so it became crystalized in the design and hasn’t changed since. Essentially, the specific shape of this API is the result of many factors of the architecture and various constraints.
For Aurelia, the modal dialog plugin came along much later and has undergone a number of significant revisions. In fact, a next major version is going on right now, so it might be a good time to provide feedback on that project specifically.
Beyond that, I could really use a concrete example with some code to help understand what you are doing a bit better. I’m sure it can be done in Aurelia, it just might be done a bit different.