Yeah, currently I introduced with some hacks only the size parameter. Some more info here: https://phabricator.wikimedia.org/T376845#11417667

There already is one. You can take the code from here: {{WikidataChart|P1082|pageIds={{{from|}}}|chart=Wikidata population (with dynamic data)}

There are two required parameters, a chart and Wikidata property to display on Y axis. Have you tried the examples slightly below?

See Module:Graph:Chart and Template:WikidataChart -- effectively, we now have graphs with dynamic data (e.g. from Wikidata) working again.

This is pretty much the biggest issue for charts in Russian Wikipedia.

The current workaround is to just remove the points outside the intervals, but this still doesn't allow 100% the same intervals as the page author intended.

No, you can't. This is exactly the "multiply the data values by -1" thing, and with it the users will see the negative values.

@Johannnes89 100% related, but I don't see in that task any mentions that originally graphs also look very small, not only blurred. Also probably the 2017 editor's is another bug.

Workarounds:
With some CSS hacks, here's what I was able to achieve on Russian Wikipedia: Template:WikidataChart (Lua, CSS). I managed to limit charts width (which otherwise stretch to infinity, producing ugly white space), but it's impossible to do that after some minimal amount about 700-800 px (depends on something?). Currently there's a hack utilizing transform: scale() to scale the graphs (as CSS zoom property messes up mouse events), but this doesn't allow arbitrary sizes (for example, you can't change aspect ratio without getting completely broken labels).

So does this mean somebody can now port Vega library to Lua (at least some very small subset of it) and we'll finally get working graphs from dynamic data (non-interactive, but still)?

Workaround:
Instead of this code (working for Wikidata):

item.editEntity(summary='my edit')

Use this (works for Commons):

data = item.toJSON(diffto=getattr(item, '_content', None))
data['claims'] = data['statements']
del data['statements']
commons.editEntity(item, data, summary='my edit')

I'm absolutely sure both of these properties should be implemented to display a button in the warning suggesting the user to autoreplace the incorrect value with the new one. There's just no sense in these properties without such a thing, and it seems like a trivial thing to implement.

Still an issue for my bot for some random Wikinews projects:

pywikibot.exceptions.OtherPageSaveError: Edit to page [[wikidata:Q8823]] failed:
Failed OAuth authentication for wikinews:de: The authorization headers in your request are for a user that does not exist here
CRITICAL: Exiting due to uncaught exception OtherPageSaveError: Edit to page [[wikidata:Q8823]] failed:
Failed OAuth authentication for wikinews:de: The authorization headers in your request are for a user that does not exist here

Why not just allow only listing all of the pages from a category (+ subcategories)? This shouldn't be really resource intensive (I think?), and cover like 90% of use cases, no? If an intersection is required, just a new subcategory ould be created, same as is constantly done now.

Why wasn't this task pushed forward?

On what exactly is this task stalled? AFAICS it was planned to be done in early 2020?

Another example of outdent creating a mess:

*** A
{{outdent}}
* B, reply to A
** C, reply to B
*** D, reply to C
**** E, reply to... D or A?

Seems it became better.

Currently they either do not open at all (as described above), or open very slowly.

This happens on any page on any wiki trying to open it while logged-in.