On the inheritance conundrum, I tried to propose an alternative to full class-like inheritance here. Basically, we could still have inheritance of storage (which covers most of the meaningful use cases for inheritance) without adding override and super.
But I'd like to make a note on the "Swift is multi-paradigm" argument for implementing actors that are similar to (current) Swift classes. While Swift is technically not married to any particular paradigm, it is also, and luckily so, not just an unrecognizable blob of random ideas borrowed from other languages.
Swift is not particularly fit for that brand of OOP that makes heavy use of inheritance (think Java), because it lacks 2 key features required from that paradigm: abstract classes and protected access. There's no way around it, and there's plenty of threads in this forums in which people with a traditional OOP background try to translate these ideas in Swift and are suggested to think in a different way. But Swift is also opinionated (again, luckily), and some of its features are consistent with different ways of thinking about problems: one key way is that "protocol-oriented programming" idea, that is actually supported by many features of Swift protocols, like associated types, the use of Self in protocol definitions, and retroactive modeling.
For an easy comparison, take for example Kotlin, a language that has nothing to do with Swift, but seems similar on a surface level: Kotlin has none of those features for its interfaces, but on the other hand it has abstract classes and members, so it's better suited for OOP, and in fact in Kotlin most designs have to rely on OOP patterns.
Also, some features that are currently lacking in the Swift model for protocols, like generalized existentials, are frequently discussed, the core team is working on them, and will provide even more abstraction power to Swift when working in a protocol-oriented way. This is the "opinion" Swift is developing over time, together with other "opinions" like heavy reliance on value semantics.
Thus, "Swift is multi-paradigm" is not really an argument in favor of a feature like inheritance of actors: I'm personally neutral towards it, because I don't care, I will only ever write final actor, as I currently do with classes. But it seems to me that the burden of proof is on the side of needing inheritance, not on the side of skipping it, at least for now.
Being a completely new feature, that especially has no ties to the Objective-C legacy, I think it could actually consider new ideas, like inheritance of storage, and only storage, which, as far as I can tell, seems to cover 99% of all use cases that I've seen in these forums over the years, and that I've personally found meaningful (also inheriting the rest of the interface, of course, but without override).