Thank you!

That seems to be a problem with the WASM/QuickJS runtime, and does not appear in Node.

I would recommend to not change this, and leave the friction as intentionally.

Yes, Z46K1 and Z64K1 is meant to be the identity, i.e. have the same constraints as Z8K5

Thank you Elena for checking so thoroughly. Closing.

Thank you Nikil!

Thanks all! Confirmed that it works. Awesome!

Do I need someone else to do this, or can I go ahead and close this as a WONTFIX, as superseded by the WASM work?

We'll take a look into this after General Availability, and see how the security situation is at that time.

Moving this to No current plans, because the development does not plan to tackle this in the next quarter or two, but this would eventually be useful.

Note that T347222 only has one implementation, and it still remains unclickable.

When one sends a 1Q to Z10012, it all works fine, so the problem is happening only on the input side it seems.

Thanks, the example on Z10012 with Q1 is indeed simpler and exemplifies this better.

I assume JSON.stringify() does not work, but curious why? Order of keys?

That is a great point.

The original task was about "It is not possible to add labels to Z110".

I can imagine some use cases for that, and it would be great to have that, but for now we will focus on other tasks first.

Just a few notes:

• Z2K3 is basically in every object, that is why it has too many hits.
• Yes, Z2 would be the best result for Z2K3.
• I hope that searching for ZnKn IDs is not something that happens frequently.
• I hope that most people who search for ZnKn actually know that they can look at Zn to find it.

We welcome patches to improve this, but the development team has no current plan to address this in the next quarter or two (sorry!). I do think that this is a good issue to work on.

Not opposed to anything here, just moving it to "no current plans" since we do not plan on working on this in the next quarter or two.

This also looks good to me and can be deployed. I see no objections from the community, and the logic makes sense.

Agreed, there have been no objections, discussion has been going on long enough, and we started the code review. Can be deployed any time from my point of view. Thanks!

The suggestion here is a bit too focused on a specific solution, which might be expensive to implement. Therefore I have taken the liberty to write a feature request here T345477 and will close this one.

More feature driven version of T343750

I really like the idea, and I think that languages like Eiffel show the advantages of these systems, but given what else we are planning to do there is no realistic chance of the development team to work on this in the near future, and thus moving this to "No current plans".

For now, moving to No current plans. This is nothing we are going to be able to do in the foreseeable future.

There are no links to that URL, so we are declining this as a task. @Mormegil , if you want to open another task for habing the page tools available, that would make sense.

I guess that is also true for type keys and for function arguments.