Klemens Böswirth

> I got points deducted because of this. I think it's just weird formatting in the feedback. The deduction was because of the missing PR for #4001 (you and @bhampl...

I don't know why a `skip` metakey would be useful here. Whether or not returning binary keys from `ksLookup` makes sense or not, is determined by the code surrounding `ksLookup`,...

I see what the idea was now. Adding `skip` metadata would be a solution for both OPMPHM pre-initialization and avoiding unwanted binary keys. However, to me this seems a bit...

I don't think a validation plugin could cover 100% of the use cases, of a `KDB_O_BINARY` option (e.g. shared mountpoints where one client needs binary, but the other doesn't support...

> These hidden keys could be used as pre-loaded "proc:/" keys so we do not need to discard the OPMPHM if proc adds a few keys. You'd have to know...

> Yes, in this proposal gopts would always add all keys, hiding the keys that are currently not used. That's not fully possible (because of arrays), but could be done...

Since it is a user-visible change, I wouldn't call it "pure optimization" (some users may have a real use case for it), however, it doesn't change any existing APIs or...

@markus2330 Is the only open question here, how many extra libraries we need? If so, I would propose leaving this open for now and creating an issue to decide before...

We could simply start by moving & merging `keyIsBelow` as proposed in #4346. That would be a sort of cleanup and would get the library started. From there we can...

> AFAICS several core functions (e.g. ksCut) depends on keyIsBelow*, so it is probably not a good starting point. We definitely do not want wrong library dependencies from the start...