sf::Drawable n'a aucune notion de géometrie ni de transformation, donc elle n'a a priori aucun rapport avec le rectangle englobant
Oui, ces méthodes : getLocal/GlobalRect/Bounds, setRect/Bounds auraient plus leur place dans Transformable, puisque cette classe possède déjà l'attribut de position, soit le premier point de ce Rect.
En fait, ces méthodes ne seraient pas virtuelles pures : elles retourneraient simplement l'attribut Transformable.bounds de type Rect. Elles ne seraient même pas virtuelles du tout : c'est à chaque classe de faire un setBounds : quand on fait un setTexture(Texture, true) dans Sprite, quand on ajoute un point dans ConvexShape. Dans certains cas, comme getSize(), qui serait directement implémenté dans Transformable, car il correspond au deuxième point de l'attribut Transformable.bounds, les classes enfant n'auraient même rien à faire. Donc on pourrait instancier Transformable.
En bref, je propose d'implémenter la Surface présente dans SDL. Elle est déjà à moitié présente : setTextureRect() par exemple réduit la surface d'affichage, ou create() pour Image/Texture/Sprite, et ce utile qu'elle le soit partout : ça permettrait de réduire la taille d'affichage d'un Text, ou d'appliquer des méthodes d'alignement en fonction de son attribut bounds comme je l'ai vu proposé sur le forum anglais. Ca permet aussi de conditionner l'affichage de Drawable autres que Sprite en vérifiant si leur bounds intersects() avec le bounds de la View.
EDIT : Je viens de voir que les méthodes getLocal/GlobalBounds sont implémentées partout, désolé, je ne l'avais pas bien compris. Est-ce qu'il serait possible de la déclarer dans Transformable pour les collections hétérogènes.
Je vais voir ce qu'offre le type erasure, mais peut-être que cette suggestion est assez bonne pour être implémentée.