Klemens Böswirth

I'm not 100% sure without looking at the code, whether or not the current `kdbGet` would clear the key. In the `new-backend` branch IIRC I took the approach that after...

I assume you mean `kdbGet` and not `ksLookup`.... Yes, it seems `kdbGet` currently just appends (IMO wrong, but it is what it is). So I'd say, if the tests works...

The docs say `kdbGet` only appends, but there could very well be a bug. There are definitely some `ksClear` calls in `kdbGet`, so it might be that the `KeySet` is...

> Is this still the problem in the new-backend branch? To quote myself from [above](https://github.com/ElektraInitiative/libelektra/issues/4093#issuecomment-1162019694): > In the `new-backend` branch IIRC I took the approach that after `kdbGet` the part...

> that the whole config of the user gets cleared (which might be persisted in a later kdbSet) is a very serious bug I don't think that this is what...

> I fully agree that we need to rethink KEY_FLAG_SYNC. How can we proceed in that matter? I didn't suggest any changes to `KEY_FLAG_SYNC` and I think there have to...

Yes, `origvalue` is broken and should not be recommended anymore. BUT _only_ using `meta:/internal/*` is not a replacement. We need a way to let plugins know, when a key's value...

> So maybe we should not make it internal and use `meta:/value/original` to store the original value? But still, only the type plugin would be responsible, otherwise there would be...

At least some of the internal iterator functions exposed by the C++ API are not use at all (or only by test cases) and could therefore be removed right now...

I think you've got most of it. But `ksAtCursor` needs to stay and just be renamed to `ksAt`. It doesn't use the internal cursor, but takes an external cursor value....