We found two main issues to support this contract standard:

• This kind of contracts could be act as an ERC20 (common token) or as an ERC721 (NFT), so we need a mechanism to distinguish them.
• When an ERC1155 acts as ERC20, it supports using the same contract for more than one token at the same time (identified by ID), so we need to take a decision on how to manage this situation (count all tokens as one, store each token's accountability separately, or only listen to a specific token ID from the contract creation).

We need to decide on solution for both issues before implementing them, but we also feel that this feature is not a priority at the moment.

100% agree. This issue right now has a low priority and first we should discuss how to manage it. Stopped until further notice.

Reading the oficial specification of the ERC1155 I found the following:

The following strategies are examples of how you MAY mix fungible and non-fungible tokens together in the same contract. The standard does NOT mandate how an implementation must do this.

Also they propose a possible implementation of how to mix both uses cases:

The top 128 bits of the uint256 _id parameter in any ERC-1155 function MAY represent the base token ID, while the bottom 128 bits MAY represent the index of the non-fungible to make it unique.

This means that there is no standard way of knowing whether a transfer event involves a fungible token or a non-fungible token.

• To solve this, we can easily support two at least uses cases (where the ERC1155 works as ERC20 and where it works as ERC721), requesting the way to work with the contract during token creation request. The remaining use case (where the ERC1155 works as ERC20 and ERC721 at the same time) seems hard to solve robustly.

Reading also the OpenZeppelin reference I found another important information:

Also note that, unlike ERC20, ERC1155 lacks a decimals field, since each token is distinct and cannot be partitioned.

This means that the ERC1155 does not implement the decimals parameter, this could be included in the metadata information, but this will require checking the metadata URI from an external source.

• The only solution is to request this information from the user during the token creation request.