I think the solution would be to distinguish between interpreter type and interpreter instance. The type should be relatively static, while the instance could be any alias/name and only generate a warning when unable to match with entries in interpreter.json. Finally the specific type would be added to distinguish the frontend-language (scala, python, R or sql/hive for spark, for example).
Since implementing this would also clear up some of the rather buggy and hard to maintain interpreter-group code, it would be a worthwhile thing to do, in any case. A final call could then look like this: %spark:dev.sql or %spark:prod.pyspark. (or jdbc:drill, jdbc:oracledw) Adding another separator (could be a period also - but the colon is semantically nice, since it's essentially a service and address that we're calling) makes for easy parsing of the string and keeps notes (somewhat) portable. What do you think?
