I have a project I’m working on that has a pop-up menu filled with buttons. The buttons are all images of identical height but varying widths, and all using different images. The menu items (buttons) change depending on which scene you’re on. From what I can gather, using symbols would be an appropriate use here, but with each button being slightly different and each scene displaying a different set of buttons, I’m not sure if it would work as a symbol, since symbols have that whole thing of you make a change to a symbol in one place and it propagates to all the other instances of that symbol. Is it possible to make the entire menu into a symbol, and have each scene display the properly-different buttons? Would it be more appropriate to make each button into its own symbol? Is this kind of use not appropriate for symbols at all?
This is a workflow I know others have accomplished and might be able to chime in better about best techniques. So I can only give you the tool maker's perspective 
.
Yes and no. Symbols are meant to be reusable components, so I'd say overall what you're trying to do makes sense and is a common use case.
The no is: The current implementation does not allow for one-off/exception properties via Hype's UI.
The yes is: This is clearly a great feature request! Right now you do have the ability to customize instances via JavaScript code; specifically you could do a flow where On Scene Load or On Symbol Load, you could make your own modifications via looking up by instance ID, plunging into the symbol, and then making modifications using the JS DOM API or Hype setter API.
Without code, I'd say the easiest workaround is that if you're happy with the final form of your symbol, to duplicate the symbol itself (not the symbol instance) and make modifications that way. Unfortunately any future changes won't propagate to all other symbols with this workflow, and lots of different symbols may carry usability and potential performance overhead.
Here’s an example that On Symbol Load looks to see which instance it is and changes text via javascript:
DifferentSymbolInstances.hype.zip (26.7 KB)
Ahh, okay, I see what you did there! While I definitely don’t mind dipping into JavaScript, it does seem like something that would be nice to be able to do with just the Hype UI. (Especially on a smaller, simpler project like this one.) Consider that a feature request! 
That said, your example also gives me ideas for more complicated dynamic menus that I could use in a different Hype project I’ve got going. Thank you very much, Jonathan!
Here are two versions that explore this.
Using @jonathan’s type of code example of changing properties in a symbol on symbol load will work for standard symbols and persistent symbols.
But if you make for example your navigation UI and then change it to a persistent symbol across scenes, the code will not run a second time. This is because the Persistent symbol will not load twice…
There are a few ways to adjust this and these are just two of the top of my head.
The first is the simplest and @jonathan has already pointed to, is to make the code run on scene load.
The extra bit will be code to determine the scene and then change accordingly. This is pretty simple.
PersistantSymbolOnSceneLoadChange.hype.zip (38.9 KB)
The second way is just as easy but would depend on your setup and if it is necessary. for example you have already made you navigation elements a standard symbol.
If your navigation is already a standard Symbol. You should be able to select it and make the selection a Persistent Symbol.
i.e a standard symbol inside a persistent symbol copied to all scenes.
The code run by the standard symbol (symbol load) will work for it across scenes.
StandardSymbolInsidePersistantSymbol.hype.zip (53.6 KB)
The code will also work from the on scene load instead of symbol load.
On scene load in most cases it seems would be the easiest option.
I hope this adds to what @jonathan has explained and not confused.
Thank you, Mark!