I don't anticipate implementing these in the upstream. Remarkup is extensible enough that these could be implemented as extensions.

See above.

Did D12730 resolve this?

This exist and has at least been minimally useful in making it easier to improve package definitions, if nothing else.

This is the same as T1849 but I'm just going to merge that here since this one is sort of more complete, even though T1849 has a great screenshot.

At HEAD, I get this:

We've never seen other reports of this, but it's <1 hour to fix. We can weave it in somewhere if approved.

Some discussion in T9367.

This is likely the same as T5030, but I haven't observed it myself and haven't spent the time to try to reproduce it.

This is a fairly huge amount of complexity for a very niche use case, which makes me hesitant to pursue it in the upstream. I expect the number of installs which would use this feature is on the order of 1, and that it essentially amounts to custom development.

We don't understand this use case, so we aren't sure how to proceed here.

This is fairly straightforward but blocked on T9132, which is prioritized elsewhere. This is likely to be completed adjacently with T9132 anyway.

We're aware of requests in this vein but unlikely to implement the specific suggestions here, for a variety of reasons. The product pathway forward here is generally a murky one. We will likely need to resolve T1460 (itself, murky) before having more clarity here. Resolving it may also introduce satisfactory threading.

This is technically straightforward but probably needs some design work. I'd guess it's on the order of 2-4 hours depending how messy application/customfield stuff ends up, although that may happen in a technical block and a separate design block. This can be slipped in if approved.

This is easy to change but I'm not really convinced it's better, even though it is inconsistent.

I plan to try to collect the above into documentation to try to better explain this, but I don't think that has any specific impact on anyone. I don't plan to make any behavioral changes. I'm open to suggestions here, but we can't write a bin/time rewind and can not fully redact data which has been committed to the system and published to email and other external channels.

Presuming this is a problem with extensions since there's a warning in the upstream.

This should probably wait for T3980 and be reevaluated after that.

In particular, I think we're going to hit cases like this:

Well, there's an unrelated bug.

(Just creating an example via email for my next reply.)

I do this routinely without errors and am not sure how to reproduce it.

This is straightforward and probably <1 hour of work. It can be squeezed in if approved for prioritization.

This probably now also blocks on T9132.

This is not blocked, but large and not adjacent to other prioritized work. I've included it in "Projects v3" (T9378).

We don't have enough information to reproduce this or otherwise move forward on it.

This is reasonable and straightforward, and I have some adjacent UI adjustments I'd like to try making concurrently. This is <1 hour and can slip in somewhere if approved for prioritization.

This isn't blocked on anything but not adjacent to other planned work in the near future. It likely makes sense as part of a "Projects v3" with T3670. I'll see what else is in queue and tentatively organize anything projects-related if there's some more of it.

Presuming this is just related to bucketing errors since we're aware of bucketing assignment occasionally being surprising, see T9372 for some discussion.

T4100 is complete and this is technically unblocked, but needs significant planning work. I intend to wait until we're closer to being able to act on it to do that planning, since things are likely to change at least somewhat between now and then.

This is blocked by T8783 (building Nuance to initial release quality) and T5307 (taking actions with search results).

I want to resolve T8588 before pursuing this to make sure the issues aren't conflated, although I think this isn't related.

I ideally want to resolve T8588 before pursuing this since it's the more fundamental performance issue, even though this isn't particularly entwined with that.

(We can cache actual image objects in the browser, although this may create other problems, and is generally a mess that needs to be individually hard-coded in every case where we show images.)

This is largely because of specific requirements from WMF, see T5685. We can reduce the number of redirects, but per requirements in that task we can not reuse URIs and can not make these resources cacheable.