Mixin calls with empty parentheses shouldn't match with classes with the same name

[amekusa]

Maybe this isn't strictly a bug report. I found the similar issue report (#2709) but this might be more of a feature request? that how I wish Less compiler works.

To reproduce:

Example Code:

// Mixin
.overlay(@z: 0) {
  z-index: @z;
  width: 100%;
  height: 100%;
}

// Class
.overlay {
  background: red;
}

Assuming you have a mixin and a class, both named .overlay,
you know, applying .overlay to an element gives different outcomes depending on how you reference said mixin or class. Now please take a look at the following use cases.

Example use cases:

// Use cases
.case-A {
  .overlay;
}
.case-B {
  .overlay();
}
.case-C {
  .overlay(1);
}

This code compiles into this (current behavior):

.case-A {
  z-index: 0;
  width: 100%;
  height: 100%;
  background: red;
}
.case-B {
  z-index: 0;
  width: 100%;
  height: 100%;
  background: red;
}
.case-C {
  z-index: 1;
  width: 100%;
  height: 100%;
}

.case-A referenced .overlay without parens, so it matched with both the mixin and the class.
.case-C referenced .overlay with an argument, so it matched only with the mixin.
And the both behaviors make sense to me (yes, I know calling a mixin without parens is deprecated).

But in .case-B, .overlay with empty parens also matched with both the mixin and the class, leading the exact same result as .case-A.
And this behavior was unexpected to me, because I intuitively expected that referencing a mixin with parens always match with the mixin only, even if there is a class with the same name as the mixin, so the result for .case-B would be this:

/* My expectation for .case-B */
.case-B {
  z-index: 0;
  width: 100%;
  height: 100%;
}

If the current behavior is not a bug, my expectation for the behavior would be more intuitive and consistent, and also more beneficial to most users, if the behavior was exactly like this:

• Referencing with parens => matches with mixins only
• Referencing without parens => matches with classes only (This also means completely deprecating referencing mixins without parens)

Environment information:

• less version: 4.2.0 (I used lessc command to compile)
• nodejs version: 18.17.1
• operating system: macos

Again, this might not be a bug report strictly, but more kind of a feature request.
The issue may not be critical and there are some easy workarounds for it for sure. I just love Less as a CSS pre-processor.
Thank you for reading. Thank you always for your hard work :) @developer