Meshes.
BlockMesh.Scale
If you set a scale property to negative, the mesh does not turn inside out. I can see why you would do this, to prevent exploitation of user meshes, but there’s no reason it needs to happen to all meshes. It’s not exactly inappropriate to have an inside-out BlockMesh, CylinderMesh, or any of the regular SpecialMesh types.
If you want to see something interesting, assign your mesh’s parent Part a CFrame with an orthogonal reflection matrix for orientation, like Part.CFrame = CFrame(0,10,0,-1,0,0,0,-1,0,0,0,-1). 
This is not an intended feature, however, just a consequence of the ortho-normalization routine accepting already orthonormal matrices, as well as preserving a negative determinant of an orthogonal matrix through normalization. You don’t want to use this in a game though, the code could be updated at any time to keep things right-side out. It’s also not reliable; the part can be subject to re-normalization that flips it back right-side out if it has physics interactions. Rotating it with code or studio tools may also have unexpected results up to and including the part being collapsed out of existence. If you need an inside out part, you should make one with flipped normals and import it as a file mesh. Support for turning built-in meshes inside out is unlikely to ever be a common enough use case to be prioritized, and it’s easy enough to make inside out primitives with Blender.
We could do so much epic rendering magic if we could set cframe to something non-orthogonal/non-unit-length 
I’ve made RHR CFrames before on accident, and I’ve seen a crossroads where all the bricks have the effect applied.
Is it possible to extend this absolute-value-of-the-input-value-is-the-value-that-is-used property to things like the MaxForce of BodyVelocity? If a value is negative the PID has some very weird effects which honestly I can’t see anyone ever using (i.e. why would you ever want a positive feedback loop like that). It will make math for the things so much easier.
I’m told by coworkers that it used to be the case in early Roblox that you could do arbitrary shears and projections with the rotation part of the CFrame. While creatively useful, this presents obvious problems for the physics engine, not the least of which is potentially having to recompute all the physical properties on CFrame change. Non-orthogonal matrices can of course change the volume, mass*, centroid, inertia tensor, collision hull, etc. of a part.
*or density, depending on what you hold constant. Weird things could happen either way.
Most cases where I’d use this would be on Anchored true, CanCollide false parts for graphical effects.
Changing part.Size causes all kinds of expensive batch updates, but scaling its cframe matrix would be extremely fast.