could you explain a little more: what i " some interesting dynamic behavior" ?

I mean , the real use case.

What about:

  $backtrace=debug_backtrace();
  echo $backtrace[0]['function'];

That seems to be also the common solution for getting the name of the calling 
function.

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.

Following Scenario:

trait TestTrait
{
  protected $var = null;
  public function setMethod($value) {
    $this->var = $value;
  }
  public function getMethod() {
    return $this->var;
  }
}

class TestClass {
  use TestTrait {
    setMethod as setMethod1;
    setMethod as setMethod2;
    getMethod as getMethod1;
    getMethod as getMethod2;
  }
}

$class = new TestClass();
$class->setMethod1('A');
$class->setMethod2('B');
echo $class->getMethod1();
echo $class->getMethod2();

This will output "BB" instead of "AB" With __ALIAS__ we could use different poperties per Trait usage in the getter/setter.
A better aproch would be usage of templates, so the setter assignment can depend on trait inlusion: Like

trait TestTrait
{
  protected $<MyTraitVar> = null;
  public function setMethod($value) {
    $this-><MyTraitVar> = $value;
  }
  public function getMethod() {
    return $this-><MyTraitVar>;
  }
}

class TestClass {
  use TestTrait as TestTrait1, TestTrait as TestTrait2 {
    TestTrait1::<MyTraitVar> as MyVar1;
    TestTrait2::<MyTraitVar> as MyVar2;
    TestTrait1::setMethod as setMethod1;
    TestTrait2::setMethod as setMethod2;
    TestTrait1::getMethod as getMethod1;
    TestTrait2::getMethod as getMethod2;
  }
}

Perhaps a naive question, but if you want a function to behave differently based on the name it has, why don't you just provide distinct functions then?

Sorry, the last comment was with regard to the original question.
Looking at the example code of 'opitz at pluspol-interactive dot de', it looks to me code generation, or templates would be much more useful here. I would not want to advocate for such usage by introducing another magic constant.

However, I also can see a point in having a magic constant that allows to define unique names for properties within a trait. But, that might be something else entirely.

Templating would be very interesting for traits but also for things like
$myConfigArray = \ArrayObject<\Project\Config\My> to have an ArrayObject where you only can add Objects of this instance. ;)

I'm not even sure this will bump the issue, but I'd still really like to see this resolved in either 7.4 or 8.0.