There are any number of ways to do ramps, and I think there are flaws for each.
Something similar to one of your suggestions was when I played with 'tying' any ramp apex to the appropriate mid-sides (for any definite orthagonal ramping) or corners (for any definite diagonal ramping) extending a conic 'pile' in towards the inner (or even eliptically to reach the opposing exge without overflowing the adjacent edges) from each such point. Then 'in-filled' over any octants spanning joining such adjacent corners+midedges concerned (and, optionally, across those between and didn't but weren't needed a same-level or down-a-level access). Easy to mathematically establish the 'mask' for every one of the cases[1].
It looked Ok in any trivial form of single-level view with hyposometric shading (floor to ceiling range) but the directional-shading alternative (either 'standard' top-left lighting or sunlight-direction hueing) necessary to seemlessly depict multiple layers (with or without bathymetric shading for depth-perspective) rather made it look less lovely than the seemless-slopes (if not being seemless onbthe boundaries
between differently-directuonal slopes).
Enforcing (or over-using) flat plateaus/strips between planar sections of ramp also makes things look odd (regardless of the rendering mask method). You get 'terraces' on multilevel slopes (rather than 'corner patios' for edge-but-not-corner-reaching conics) where you'd expect a more steady hillside. And what you do with concave slopes matters a lot. Ditto 'saddle' configurations, and multi-saddled ones. (Not that they are too common in natural landscapes, but they do occur, and can be expected to arise in deliberate player building/digging operations.)
...sorry, I've just thought/experimented a lot about this subject. In leiu of having put any of this information to good personal use, I'm left trying to put into mere few words what is probably better dealt with in any number of properly annotated diagrams in a whole dedicated essay on the subject! But make of it what you can.
(And, yes, wot Meph sed. While I was trying to make this post not look
too dense and unreadable, and failing.)
[1] Actually tried it out on triangular, square and hexagonal tiles (plus, for a laugh, pentagonal ones, assuming a spherical geometry (dodceahedron), just because it sat in that sequence. Obviously, tri-tiles have the least self-set details (especially after reducing to archetypes to cater for every rotation and reflection), but are complicated by each corner-connection
may have to link nicely with three ( 6 - self - (2*side_adjacent_tiles) ) 'diagonals', depending on your given rules for inter-tile movement, and that hurts when adding a sufficiently "neighbour aware" tile profile. Hex-tiles are actually much nicer (even more so pents, unless you go with a hyperbolic geometry instead) as they have six edge-neighbours, but
no corner-only ones, so you can reduce the archetypes (or complications of procgenning each tile mask on-the-fly) quite ignificantly. Square-grid tiles are actually not very good, except for being easier to work with in raster-graphics rotations without fudging integer triangular coordinates (and, by extension, hexagons) from a half-a-diamond that has cordinates coming from a sheared-square. ...Or so I worked out at the time. But I probably missed half a dozen other data-tricks that actually can be used, as I only did all this for my own entertainment.