I want to help here/implement this.

Please give any tips @Mingun, especially for the interface/API you'd like for this:

1. Yet an other function for Writer, like Writer::new_with_indent_MORE
2. Using a configuration struct like xml-rs has it: Writer::new_with_config(config: &WriterConfig)
3. ... something else?

Why I want this

To store XML files in git, it would be nice to have a fast, reliable, one-way git-filter that gets applied to all XML based files (especially interesting for SVGs, to me), to a very stable, fixed standard, applied by everyone (in a project/repo).
This is one key requirement I see for that purpose, apart form some sorting of elements and attributes, which can be done already with quick-xml. An other - less pressing - thing would be, to try to preserve comments; I have no clue how well quick-xml fares in that.

... thinking about it ....
would it ever be a viable scenario, to auto-convert all XML based files in a git repo, before checking them in?
If one did not have 100% trust in my code an in the used XML library and the human or software that wrote the original/input XML to be correct, this could potentially result in data-loss.
From some testing I have done in the past with a few other XML prettifier tools (none rust-based though), I often got out faulty/missing/altered data/content.

How confident would you be about quick-xml in such a scenario?

I can't imagine which API will be convenient without using it. Probably we should start from adding methods to ElementWriter. Probably this API can cover basic needs:

writer
  .create_element("element")
    //.new_line() (1)
    .with_attribute("first", "1")
    .with_attribute("second", "2")
    .new_line()
    .with_attribute("third", "3")
    //.new_line() (2)
    .write_empty();

<!-- result of the code above -->
<element first="1" second="2"
         third="3"/>

<!-- if uncomment (1) - indent depends on indentation settings - 2 spaces here -->
<element
  first="1" second="2"
  third="3"/>

<!-- if uncomment (2)  -->
<element first="1" second="2"
         third="3"
/>

How confident would you be about quick-xml in such a scenario?

Personally, I've never use it for writing XML documents, all my needs in reading them. There are also not so much tests for writing capabilities, so some bugs can exist. Improving our testsuite and fixing them are welcome. From the other hand writing is much more simply then reading, so the probability of bugs is reduced.

What about setting a property on the ElementWriter once, which automatically inserts the newlines, as opposed to adding each of them manually? Any reason to prefer the latter over the former?

That is also possible solution, in addition to manual control. I think, it can be implemented in the follow-up PR.