Rich: Tl;Dr custom elements are a badly designed primitive and I

can't recommend them in good conscience.
There are a few different strategies that frameworks can use to handle this problem:
Always set attributes. This is what React does IIRC, and it results in the opposite issue — custom elements that define an interface using props instead of attributes are essentially broken in React. It also means you're limited to passing data that can be stringified.
Always use props.
Use some heuristic for determining when to use props and when to use attributes. This is what Svelte does, and I think what some other frameworks (Preact, maybe?) also do, because empirically it appears to be the most broadly compatible approach.
Invent some new syntax for differentiating between the two. This is what lit-html does, for example (foo="attribute", .bar="prop"). But then you have to either a) introduce an inconsistency between custom elements and normal ones, or b) make people write <input .value={foo}>, which is a bit gross. It forces people to understand distinctions that shouldn't matter in day-to-day situations, and means that the Svelte language is no longer a simple superset of HTML. People proficient in HTML would then have to learn what is essentially something framework-specific.
None of these options are ideal, but it's what's been forced on us by the design of custom elements. (Imagine if we'd designed them in such a way that attributes were simply the inputs to a function that generated initial props when a custom element was instantiated, and from that point forward you only had to worry about props? We could have avoided all this silly confusion.)
You're right that it's not future-proof. Unfortunately, custom elements are themselves not future-proof — any new attribute or property that applies to HTMLElement will potentially conflict with custom elements being used in the wild. Smooshgate, except that we encouraged people to pollute the language!
Unfortunately I just don't think there's a good solution to this. Which, along with other serious shortcomings (global namespace, no SVG support, no SSR — and no, declarative shadow DOM won't fix that), is why I personally advise against their use.
A possible workaround in this case would be to implement prefix on any elements that use it as an attribute:
class Foo extends HTMLElement { get prefix() { return null; } set prefix(value) { this.setAttribute('prefix', value); } }

Я вообще считают что ui-фреймворк не должен завязываться на dom и особенности html (а также css) а должен использовать html/css просто как бекэнд для отрисовки компонентов. Потому что кроме html/css еще есть svg, есть canvas и наконец есть webgl (а если выйти на уровень нейтива в мобилках или десктоп-приложений то там еще прибавятся способы для отрисовки ui) И мне кажется все идет к тому чтобы написать весь интерфейс ui один раз на компонентах фреймворка а потом только изменив в конфигурации настройку движка рендера получить отрисовку не только в html/css а и в svg или canvas или webgl и т.д