I am not a Vue guy. I am building custom components, so I am facing a similar problem (without frameworks). To start of my comment, let me first tell you how it is done elsewhere.

When using WebComponents, my approach to propagate things is to fire events. Events have been a part of the HTML / JS world for quite a time, and all the standard components use events your JS can listen for in order to tell JS that something is happening. Let's say you build a form components. Inside, you use form-building-block-components, for example a component which renders a username/password group with domain-specific validations. Inside that, you make use of your own username-input-component, which only allows a certain format and is rendered in a certain way. You want to insert the form into the document and use JS to listen for the submit button somewhere in the Shadow DOM.

Imho, propagation should be done by events, and property-propagation by exposing fields on the element, which higher-up components can make use of themselves, and fire their own stuff in return. The custom input field should fire an event onChange and expose fields or getters to read the value from (just like with regular HTML input fields). The group should also fire an onChange, and expose its fields' values in the same way as the input field. The form can listen to those events, and update its own fields, and then onClick of the submit button, fire an onSubmit event. All your JS then has to do is listen for the onSubmit event of the form and read all the values of the form from its fields.

Unfortunately, I am not a Vue guy, however, I heard that Vue does this whole thing backwards. With what I just said above, going the other way is easy, too. All you have to do is define a model, which can be filled by a child element, and then pass it down to the child (passing an object in JS passes it by reference, so all changes you do in the child are available to the parent as well). Compared to my approach above, the parent defines the fields instead of the child. In the end, you hook the submit buttons click event and read the object ref, which you may keep in a global store (or just in the parent component), in order to do final processing and submission in any way you see fit.

As for

In one of our forms we used a store and made it unmaintable.

In Vue, you seem to have to use stores and models to work around propagation. In the context of the sentence, I also think that you are doing something wrong there, because a global store is not about using a store for a form, but using a store for all the properties on the page, which you can access if needed.