Database and record structure

1 -  Subfields available other than: "Last name, First name, suffix/addition"

2 - Horizontal links: (a) between databases, (b) between records (1:1, 1:n), (c) between list entries

En: no

It can have links to localy attached files, to Internet remote resources via an URL

3 - Database subsets 
    1.     marked records
    2.     virtual sets (groups, folders: pointers to records without physical duplication)
    2.1   nested (hierarchical) groups
    2.2   live/smart groups
    3.     custom/built-in groups
    4.     other

En: 
1: no marked records as such 
2: sets and their subordinate groups of virtual records (user's group: up to 500);
2.1:  groups cannot be hierarchically nested; 
2.2: yes they can be smart/live, i.e. acting as a query which points to the records that match it, the query can be the same as a normal one
3: Custom -static or live- and Built-in, a) custom static: a container of pointers to records, same record can be in more groups
b) smart/live (see 2.2): they represent a query which has been converted into a smart group
c) built-in, i.e. automatically created: all references, retrieved search results, unfiled, online search results, Word or OOw cited, trash, imported, duplicates, Find Full Text, EndNoteWeb ...
4:  can combine -up to 10- groups, via a boolean search, to find overlapping/excluding/common references: | Groups | Create from groups in a new named combination group (which acts like a smart group)

5 -  Hierarchical links (es. thesaurus, mother/son(s) records, records and attached text-notecards-ideas)

Term Lists cannot be regarded as really autonomous (see dedicated section: Term/Entry lists)

6 - Ready, predefined, record structure: features of reference types

En: yes, according to RT-reference types + other default preferences; Preferences are all automatically shared among different shared databases on the same computer, i.e.: not shared, separately for each PC user.
Fields in each RT bear a "step" displayed name, in fact they are identified by the position/role they hold in the Generic RT, which is fixed across all reference types. Some fields (e.g. names, journal titles, pages, URL, keywords, figure, caption) have attributes that cannot loose or lend to other fields; the link between a term list and any field is customizable;
when a field is deleted from RT (or mismatched), existing content is put to the corresponding Generic RT field; no numeric fields available, apart from RN for sorting; if fields names are changed in RT, styles are automatically updated, searching and global editing are not affected; styles recognize specific field names 

6 - Number of RT record types

7 - Can modify the exisiting RT record types (apart from changing name to RT or fields) and create extra

8 - Number of fields per record

9 - Can create extra fields

10 - Fields attributes can be changed; can be applied to other fields

the attribute 'field linked to a term list' is customizable insofar as a field can be included in only one list, while a list can stem from a cluster of fields

11 -  Multi-value fields allowed

En: yes, names (authors, translators etc.), and kw are recognized as such in: indexing, sorting the first author, output as far as subject bibliographies; style design only recognizes and manipulates authors: kw, File attachments, URL any other ... one per line, or as they are stored in the references
term lists and subject bibliographies can recognize multi occurrences through different separators in any and every single field (<CR> is always accepted)