I think this is equating nominal subtyping with inheritance too strongly, when code reuse and subtyping are really orthogonal axes that can be bundled together (as in C# class inheritance), but could equally be separated so that type inheritance and implementation inheritance don't need to imply one another. There are both models that are essentially forms of inheritance, and models with a different conceptual approach, that enable code reuse without reference to explicit subtyping. I worked on a structurally-typed research language called Grace and we explored many different inheritance models for it, without affecting the type system.
I'm going to start out with reference to Object Inheritance Without Classes from ECOOP 2016, which describes several object-based code reuse mechanisms for a structurally-typed language, and then go on to some further approaches. It sets out a matrix of different models and different properties that you might want, or might want to avoid. The first few are variants of prototyping, there are a couple that emulate different sorts of classical inheritance, which I think you won't want, and then there's something that's more of a trait algebra. It presents all of them using the terminology and syntax of inheritance for convenience, but you could describe each more specifically in your language.
The first model it terms "forwarding": when an object doesn't understand a message/method call, it just passes it on for another existing object to handle. All the methods from that object are available to call on this object, This is the fundamental model of E.
The second model it calls "delegation": a method that doesn't exist is re-sent to another object, but the self-binding is preserved, so when that object accesses one of its own methods or fields, it's the version from the sub-object that it gets. As in forwarding, all the methods from the other object become available on this one, but those methods can make downcalls too. This is the fundamental model of Self and JavaScript.
The third model is "concatenation": in this approach, the entire body of another object is copied into this one (methods and fields alike), and definitions from the current object are added "below" them. The last-added definition wins. I believe this approach was first proposed as OO inheritance by Antero Taivalsaari for Kevo in Delegation versus concatenation; or, cloning is inheritance too.
The paper uses object { inherit expression } for all of these, where expression can resolve to any object, including both existing ones and newly-created ones, and the whole thing is an object literal. A class-based system could similarly do this either at the class definition or at instantiation time, and you could say "forward" or some other keyword if "inherit" is too loaded a term. I would say they're all approaches to inheritance, but they're all independent of subtyping too.
All of the models above easily generalise to multiple parents, with some way of determining the order that those other objects are used. In all of them, an existing fully-complete object is used as the source of code to be reused. Those objects could be independently meaningful or used solely as sources of code to reuse.
The paper proposes a few other models that probably aren't relevant to you: a "merged" and "uniform" identity that emulate some kinds of class inheritance using factory methods, and a very strange imperative "positional" model. All of these are still set within the structurally-typed language and don't involve nominal subtyping, though.
Its "method transformations" approach is in effect a form of a trait algebra with stateless objects as traits. An object can inherit from one or more stateless objects, choosing to alias or exclude certain methods within them and acquiring the rest as its own methods as-is. The final object will have methods from all its parents as well as those defined locally, and ends up with the union of all sets of parents' method signatures, plus aliases, plus its own new methods. This is an emulation of a native trait algebra, and if you're happy to extend the language with explicit traits I think those will be more convenient. For very simple needs, even just "copy this entity's methods in" like Ruby's include is effective.
There's a table on page 21 of that paper that sets out different trade-offs that are made between its different models. All of them are entirely structurally-typed, but differ in what the methods you acquire can do or assume about they object they're now in, and where you can get them from.
A further approach would be something like C#'s extension methods: external definitions saying that any object with a certain type gains this additional method. A method can be defined once, and then reused as part of any compatible object, so e.g. something like string b(this { int a(int) } self) {...} would make any object with a also have b. This can work for structural types the same as it does for nominal. There are complexities here that make caution advisable: because this is not opt-in at the object level, there is action at a distance and scope for conflicting definitions to arise, and it has the effect of implicitly extending the structural type with a new member not mentioned as part of it. It's superficially an attractive approach that seems "more structural" than definition-side reuse, but the complexities aren't trivial.
Alternative post-facto extensions:
Given that you already have named classes, there is also a "reverse inheritance" approach: a new class can define methods that it injects into a list of existing classes by reference, without requiring any particular subtyping outcome. These would be part of the objects from birth.
Depending on your programming environment, outright copying code may be suitable. For example, Self's editor included a "copy-down parent" functionality that automatically propagated changes made in the code of one object to another. This is viable in an integrated image-based programming environment, but not quite as much in a text-oriented flow. Macros or outright textual inclusion can accomplish similar things.
Another approach to code reuse is through programmatic transformations. Object systems in Lisps often have macros for manipulating classes or objects to insert new definitions, as well as the obvious "macro that expands to method definitions" possibilities.
The simplest object-oriented mechanism of code reuse is just ordinary object use: your class's methods can explicitly call methods from another object. The prototype-based mechanisms above are versions of automating that, but simple parameterisation works too. There are dependency-injection techniques that can be repurposed for simple code reuse. Aspect-oriented programming provides a form of code reuse by injecting code to execute at fine-grained points in execution.
The final approach I'll propose is to use the class inheritance mechanism for the reuse features, and leave out the nominal subtyping features. There's no reason that class X : Y needs to create a type hierarchy when you don't want it to. In a structurally-typed system, classes do not define types at all, so it couldn't! A class as a package of members you can instantiate into an object can just as well also be a package of members you can reuse in another class. Instances of X will probably be a subtype of any type that instances of Y have, but that's inherently true of any form of reuse that adds methods to your objects. Perhaps you'd say only classes with a nullary constructor can be used this way.
There has been a series of academic workshops called MASPEGHI and MASPECHI that covers mechanisms for specialisation, generalisation, and inheritance. A lot of speculative approaches and implications of feature combinations can be found in its various proceedings. One complete proceedings is here, but others seem to be scattered all over. There will be many plausible designs within those, as well as some experience reports on approaches that might identify limitations or benefits of them.
