Merging could also be partial, instead of none or all. For example:

• If basic widgets (wiki lists and tables, etc.) are added to PhpTags, then PhpTags Widgets could still provide additional things. It could have any "extra" widgets that are more specialized, require more Javascript, etc.
• If you add data storage and querying in PhpTags itself, then maybe some PhpTags Wiki features would also make sense to have. (Support for categories, for example.) But there may still be things in PhpTags Wiki that are "extra" features and can be kept separate.

Perhaps PhpTags could have more basic functionality, and more classes or interfaces that are starting points for implementing more. Then other extensions could rely on this instead of each other when more advanced features are created.

One example: I have been thinking about later making a "PhpTags Page Relations" extension. The idea is to use query objects recursively to build relation structures for pages. For example, follow a property relation from page to page - whatever is in the query that is passed, it is done repeatedly, up to a certain limit or until there are no more results.

If there were common "QueryObject" and "ResultObject" classes (or instead a "QueryInterface" and "ResultInterface"), then this could be used as base classes (or interfaces) in PhpTags and in any other extensions that implement querying. Then, a "PhpTags Page Relations" extension could use those as arguments and support all querying systems. Widgets could also support a "ResultObject" or "ResultInterface" to provide universal "result formats".

Sounds good, probably it still needs to mature for possible to separate the stable basic things from additional.
it seems to be exactly what necessary.

I've thought more about PhpTags Functions, which is the one extension among those you are considering that I didn't mention.

PhpTags Functions seems to be the most mature extension for PhpTags. Some additional functions may be added in the future, but everything else will probably remain mostly the same. It will probably also be used by most people - but not all - who use PhpTags.

So, I think you have an easier choice here. If it would make development simpler to merge it into PhpTags, then I think that's the best option. Or if it's simpler to keep them separate, then it's probably best to do so. Otherwise, it's a matter of taste.

If instead, you are considering a partial merge, perhaps the class for native objects is a good choice. In the future, perhaps additional "useful functions" may also be added that are not only for PhpTags users, but also for use inside PhpTags extensions. (A "library" for PhpTags extension developers.)

@Pastakhov: Hi! This task has been assigned to you a while ago. Could you maybe share an update? Do you still plan to work on this task, or do you need any help?
If this task has been resolved in the meantime: Please update the task status (via Add Action... → Change Status in the dropdown menu).
If this task is not resolved and only if you do not plan to work on this task anymore: Please consider removing yourself as assignee (via Add Action... → Assign / Claim in the dropdown menu): That would allow others to work on this (in theory), as others won't think that someone is already working on this. Thanks! :)

Hi, I still plan to work on this task