The use case is the following - it is a workforce planning app, and the client wants to set up a list of increases. Each increase can be applied to a subset of employees, as determined by their band grade. They want to be able to set up the filter to be for example 'P%', which means it should apply to all P bands, or 'PB%' to all bands starting with PB
I was trying the text approach purely because it gave them similar functionality to what they are used to, where they can set up their filter very flexibly, including setting up exclusions the same way (they were on a homegrown SQL based system). Also Band is not a dimension, but a smartlist account, so there isn't a hierarchy I can easily use to filter (i.e. there is no member corresponding to P under which all P bands exist). I did not want to embed the filtering logic in a business rule, but give the users the ability to set up the filters in a web form.
At this stage I am thinking of having another smartlist member with just the main bands in it, so that they can at least filter by main band, but unfortunately it will not have the same flexibility as the SQL based approach they are used to.