Yeah, I have also wanted something like this. I think it’s quite similar to this previous request by Chris himself 
The question I usually ask myself when considering whether to create a new Type is whether there is any actually useful data beyond the name that I would want to store there. Whether there is any actual utility in having a full-on Entity for every option (of course options in multi-select are basically entities already, I think, but still). Anyway, in many cases the answer is no, I just want a common set of options. There are some examples of these solutions from Fibery itself, such as the newer “World” Types, but honestly I think that’s a great example of where a Type can be overly “heavy” as a solution.
The World “App” actually has tons of maybe useful data in it, such as TLD, “region”, etc. But I am willing to bet that most people who want a consistent list of countries to choose from actually do not need 90% of that additional info. It’s sort of just there because, well, it had to be made as a Type to be usable in multiple other Types (because of Fibery limitations, really), so you might as well add a bunch of additional info just in case. But the reality is that for most people a simple list of countries, expressed in a single-select, would probably be fine. Perhaps even preferable. In the case of the currency “App”, at least it is pulling live rate data (I think the country list is updated too, but still), so it seems to have more reason to be an “App” with Types to me.
This actually raises an idea I haven’t necessarily seen discussed yet, which is something like 1: a “data store” (“array”?) type of field or other “object” in Fibery and then 2: the ability to reference data to populate options of a field. This is different than the existing “Lookup from”, although perhaps it could work similarly. The idea is that it’s not pulling the actual, selected value(s) from some other already connected Type/Entity. It’s pulling the data from a Field (or other data store?) and representing it in one of several different ways (perhaps).
Like let’s say you could do this, reference data somewhere from a field, then set the field data type, and the referenced data would be represented differently depending on that. So if it was a Rich Text field, it would just instantiate all the data there in markdown or plain text, I guess. If it were a multi-select, it would show all the options, and allow you to select from them. I’m kind of thinking out loud here, and realizing that it only probably applies to a limited number of field types, which may suggest it’s not a universal enough concept, or perhaps just that it would filter the list of what field types you could select…
Anyway, that idea would address your need and perhaps some others. Like many things in Fibery it might be usable in creative ways. Or at least the idea could be adapted into something that could (the ability to have “data objects” that exist somehow independent of Types might be very useful for sophisticated formulae for example). I’d welcome any thoughts to refine it, it’s definitely raw…