Pekka Klärck

The tag should probably be `robot:flatten-keywords` to make it more explicit what it does. Same naming convention would also work with `robot:remove-keywords`. I'm not entirely sure about the `s` at...

We'd probably need both `robot:flatten` (same as `--flattenkeywords`) and `robot:remove` (same as `--removekeywords`). To make these tags easier to understand, naming them `robot:flatten-keywords` and `robot:remove-keywords` might be a good idea....

This change only affects Robot's logger that writes output.xml. This could probably be implemented by creating different XmlLogger variants for different usages and switching that when needed. Or perhaps XmlLogger...

The problem this issue tries to solve is with output.xml (and log.html created based on that). I'd concentrate on that simply because it's a lot less work. There could also...

On our Slack someone proposed this kind of functionality and I mentioned this already somewhat old issue. Since I last commented here, issue #2603 adding support to control the continue-on-failure...

Do you have concrete examples how it should look like? Are you interested to help with development?

Issue #4276 proposes similar functionality with a different API. It has a benefit that each failure would get a timestamp that would match the time the failure actually was detected....

Better to do this change in RF 5.1 than 5.0. That gives time for those who prefer the PIPE behavior to explicitly use `stidin=PIPE`. Those who don't want that can...

Because users can opt-in by using `stdin=None`, there's no hurry to change the default. Better to do that in the next major release where backwards incompatible changes are safer. That...

Showing return type information in Libdoc output would certainly be useful. The biggest question is how to show that information. Options include: - Add new column. A drawback is that...