Wrapping classes vs. extending classes inside of Advisor

Unfortunately your description fits class extension as well as wrapping.  I was looking for something more specific.

Assuming that we don't have any lingering confusion about the difference between the two approaches, my question to you would be--why define the wrapping class inside of Advisor?  What advantages does that approach provide?  In our experience, the other fields on the wrapping class are being added to help the Advisor project navigate a flattened BOM.  We find it advantageous to set their values in the class constructor outside of the Advisor project in order to help keep that logic distinct from the actual business rules.  The wrapping classes are also then exposed to the outside (non-Advisor) world, in case anyone needs to look at the class definition.

One guess at your possible response ito the above questions is that the wrapping classes then don't have to be imported into the Advisor project.  However, if you put them in the same package, the effort involved in importing is trivial.