Hello Tumult,
Hello @jonathan,
I think adding symbols using the API (and on the fly) would really make Hype reach the next level. Is it possible to Elaborate if this is on the roadmap and what is holding this feature back until now?
Best regards
Max
I can probably guess at the response for this one 
"We don't comment on our future roadmap" - quote
I would think that performance issues (and this is only speculation) would be a reason as Symbols are a complex-ish organism and having the ability to create - recreate and keeping all timeline info and everything else associated could be a difficult task too. Just my 2 cents.
I am asking as the runtime has the functionality included but doesn’t expose it. Surely there needs to be some additional triggers when symbols are added after scene load but it would potentially be possible (in my opinion).
And sometimes the answer is also … nice idea … this and that technical detail… but will not be part of version 4. 
"Being open with v4 is an oddity for us"
I guess true but for this type of functionality I'm guessing .... the former.
I'm actually happy to elaborate if you're interested in how the sausage gets made 
. Story time below....
The runtime actually doesn't have this functionality! If it did, I'd definitely expose it as API in a frame tick since it would be a great feature to add.
Let's travel back to the v2 days, before v3's Symbols, and before the notion of a Professional variant of Hype. It was early 2014, and about the only app that used a feature called "Symbols" was Adobe Flash Professional. There was a very weird workflow where to get nearly anything done in Flash, you'd have to go though this "Convert to Symbol" phase and chose a type of symbol called a "Movie Clip." Suffice it to say this was not the height of good UI!
Hype documents were trending to be more complex, and it was clear users needed tools to help reuse components to help manage that complexity. Initial debates were about if this should just be reusable animations to entire multiple-scene documents. Eventually we settled on a scene-within-a-scene concept. To implement this, it required the largest changes and refactoring to Hype's code base that had ever been accomplished. This was no small task in scope and time, so we did look for ways to minimize the risk and work involved.
One of the decisions had to do with runtime support.
An observation about the Symbol implementation is that it made use of all pre-existing concepts in Hype - elements, timelines, and animations. This meant that instead of writing out the symbol and making various instances at runtime, the instances of the symbol could be created at the export time as if they were ordinary elements.
The Pros:
The Cons:
From a user perspective there's really not much difference where the instances are created because the result is the same. As we were really not sure if people would even grok Symbols or ever use an API, it seemed to make sense to go with the most expedient method to make the instances as part of the export process. And, this could always be changed later!
So the current state is that the runtime has very little knowledge of Symbols. There's a little bit sprinkled in to deal with Persistent Symbols and also Symbols' independent physics environments.
As a side note, I was quite opposed to calling them "Symbols" and definitely did not want a menu item called "Convert to Symbol" since Flash left such a bad taste in my mouth. We did use this name as a placeholder until we could come up with a better idea. As we had mostly wrapped up the feature, Sketch released their v3 that included Symbols. At the time it was rough compared to our implementation, but given Sketch's popularity we decided naming consistency would work in our favor, so we kept the Symbol feature name. Having this only be in the domain of the Hype Professional upgrade also swayed me that it would be okay. Now lots of design tools have Symbols!
It turns out Symbols in Hype are far more popular that I ever expected. (Frankly, I think they are over-used, but a creator can never dictate how their creation is used!). There's a lot from the original drawing board for Symbols and plenty new ideas that we'd still like to implement. Making use of JavaScript with Hype has also become more prevalent. There are some other cases as well for dynamically creating HYPE_elements. This all points to better control via API.
(I will sorrily say this feature won't make the cut for v4.0.0)
Thank You Jonathan - very insightful!