Hi:

From my point of view, it is not the same property.
My understanding is that you are moving here very much in the area of the typical diamond problem of 
multiple inheritance.

Theoretically, it is not clear whether the two properties should be handled as the same or not.

Why would you want to apply the trait a second time?

Best regards
Stefan

We can agree there's only 1 property definition right?

The concrete classes Foo and Bar will never define that property since that would be a "real" conflict.

So if you know that Bar::$prop is initially resolved from A::$prop as well as B::$prop you could say it's the same definition...

Why i want this? I want to extend a package in a subpackage on class level as well as trait level. The concrete subpackage classes extend the corresponding package classes and i don't want to override the package trait functions in each subpackage concrete class so the subpackage comes with its own trait, build upon the package trait.

It's really an architecture thing..

<?php
namespace Base {
    trait MainTrait { public $prop; }
    class Main { use MainTrait; }
}
namespace Base\Sub {
    trait MainTrait { use \Base\MainTrait; }
    class Main extends \Base\Main { use MainTrait; }
}

No, I disagree with your premise.

They are two different properties.
Look at the output of the following program.
This is a perfectly valid usecase and avoids name clashes.
Yes, the visibility is here private and it makes semantically a difference.

But still, defining a property with the same name in two classes in the same inheritance chain is always a code smell. And that is exactly what you are 
doing, since you got two 'use' declarations.

I can see your desire to make it logically one, but that does not fit into the 
idea of flattening a trait into a class.

<?php
error_reporting(E_ALL);

trait A {
    private $prop;
}
trait B {
    use A;
}
class FooT {
    use A;
}
class BarT extends FooT {
    use B;
}


class Foo             { private $prop; }
class Bar extends Foo {	private $prop; }
$o = new Bar;
var_dump($o);

$o = new BarT;
var_dump($o);

Of course.. private visibility.. you sir, are a genius :')

I get away with this since the trait is mainly for accessors only.

However, i have this (personal) convention to use protected properties with accessors, mainly pragmatic reasons (overriding default values by defintion). I think i'll need to revise my conventions for private properties usage, perhaps the strict way.

http://fabien.potencier.org/article/47/pragmatism-over-theory-protected-vs-private

I cheered to soon :-) now Bar has 2 individual property definitions (makes sense ofcourse), so this doesn't solve my architecture problem.

We can debat on if the architecture is a code smell or not, but i can understand i'm overusing traits here. Traits are simply not suitable for this.

I'll revise it so that the traits complement each other, rather than "extending" each other.

Also i did'nt read your comment well, especially the "semantical difference" part.. ;-)

E.g. something like;

<?php
trait A { }
trait B { }
class Foo { use A; }
class Bar extends Foo { use B; }

So it seems this request can be closed?

Yes.