If this restriction is intended to protect users from confusion, please don't — the context in in-interface vs. in-interface-list is already doing a fine job. 
If it’s an architectural legacy, I’d much rather see the limitation fixed than have an implementation detail dictate my naming conventions.
As far as I'm concerned, if your naming convention involves giving everything the same name, it's flawed from the start.
It is better to leave no room for ambiguity.
rextended :
Especially this approach
pekr :
Be glad that they cannot be renamed 
Please! Please! Please!
Do not allow interfaces and interface-list have same name...
It would be a nightmare!
Specially in attributes where you can chose or a interface, or a interface-list. Example OSPF Interface Template.
Interface lists are not just used in firewall rules, but also in several other places. Did you try adding a /interface bridge port entry with interface list for example? Or as tagged/untagged members under /interface bridge vlan?
Now imagine what happens there if a list is allowed to have the same name as an interface.
But that (ridiculous) request surely stems from the fact that the user,
who hasn't deigned to reply so far,
uses just two or three functions here and there, rather than VLANs...
OT / P.S.:
studio.2zone.cz no longer exist?...
I use a "my own" standard:
Every interface list name begins with "if-list_"
I know it sounds redundant! But it made my life easier!
Auto-Complete smarter...
Avoided our Customers(ISPs that contracted our services) get confused.
How is it a convention if it's not functional, dear laddie?
well, I use "list-" / LAN / WAN / MGMT / etc. , and I avoid "_" on any name.
Everyone has their own standards,
but wanting to give a list the same name as the interface...
Could it be that the account was hacked and an AI bot is now messing with us?
Any special reason to avoid "_"?
Could you please stop making this personal? Whether I use two RouterOS features or two hundred has nothing to do with the architectural question I asked. And digging through my profile to comment on an unrelated old website adds nothing to the discussion. Thank you. I may still respond to some of your other posts where they address the actual topic.
Thanks for your input. I can certainly see why a convention such as if-list_ works well, especially when managing configurations for customers.
My point is slightly different, though. I don't mind naming conventions where they add useful information; I just don't like having to introduce one purely to work around a namespace restriction, unless that restriction is technically necessary.
My original use case was very simple: I was creating security/policy zones using interface lists. One tunnel happened to be the only member of its zone, and both naturally had the same name. I deliberately wanted to keep using in-interface-list / out-interface-list consistently rather than make that one zone a special case using in-interface / out-interface.
That made me wonder whether there was some deeper RouterOS reason why an interface and an interface list could not share a name — perhaps CLI, scripting, or properties elsewhere which accept either type. Some examples in this thread show where ambiguity exists in the current implementation, but I'm still not convinced that different object types inherently need to share a namespace. A UI or CLI can represent the object type explicitly.
More generally, I actually find RouterOS somewhat inconsistent here. We have address lists and interface lists; interface lists can even include/exclude other lists, effectively creating a small hierarchy. Yet there is no equivalent port/service list or more general grouping model. So this is interesting to me beyond just finding another spelling for myIQ_TOWERS tunnel.
I've worked with FortiGate as well, so I know that a richer object model has a cost: dependencies become more complex and deleting an object may first require resolving references elsewhere. I'm not suggesting RouterOS should become FortiGate. I just don't think avoiding that complexity automatically means that naming restrictions are the best abstraction.
And that's really why I asked. if-list_, _LIST, ZONE_, etc. can all solve my immediate naming problem. I'm more interested in whether the limitation itself is necessary.
Without the restriction, behavior would be ambiguous anywhere RouterOS can take either an interface list or a single interface. They could make a rule that says which one wins, but now the user has one more detail to keep in mind, when the original wish was to simplify things.
Personal?
It seems to me that you're the one making this personal;
if I stated the facts and that bothers you, it certainly isn't my fault...
Or perhaps you took issue with me because I was the first to reply,
and everyone else (regardless of what I wrote) ended up opposing this request anyway?
Is why I wrote OT / P.S....
Obviously, after reading a request that struck me
(and apparently others, too, whom you carefully avoided answering)
as ridiculous, I checked to see if the profile was AI-generated, stolen, or what have you;
because, I repeat, such a ridiculous request warranted some investigation.
Besides, I wasn't prying into your personal affairs.
If you want to keep a link to a studio that likely closed years ago, that’s absolutely fine by me,
but expecting people not to look at your profile... You should hide it...
otherwise, people might break it just by looking at it so much.
Alright, now point out where I made a mistake in what I wrote.
If you had used that function (or similar ones) you would certainly have already known about the risk of ambiguity,
and you probably wouldn't have even started this topic.
I don't like him... (I do not like be under_score)
That was just an example; I really can't stand that character.
Maybe someone in this topic (aside from the OP) feels the same annoyance when they see my icon.
Myself, I tend to use underscore more than dash, since 45+ years on *nix has burned "-" in as a command delimiter, and not a text character. (Kind of like the mass stupidity of backslash ("\") showing up in written text, which isn't a "real" character either, just MS bullpoop . . . )
CP/M 86...
And the spaces on name of something? (or better one at the start or at the end?...)
The idiocy of hiding file extensions?
You know, if you start that list, there's no end to it...
And the name of that list is Macro$hat . . . (and I won't waste the time to discuss that turd either . . . ).
I just lament that it has crossed over into everyday writing and not stayed whence it came (and belongs) . . . It really makes folks come across as idiots.
Forgive me, but what do you mean by "writing"?
I mean, are there people who actually use it for handwriting?
For messages that have nothing to do with DOS or Windows?