Address scopes is a slightly fuzzy concept in IPv6. We see them on unicast addresses, even though technically they are defined on multicast addresses. Potentially there could be 16 multicast scopes, since they use a 4-bit field for them. So far only 7 have been defined with 2=link-local and e=global being popular. 1=node isn't heavily used. No one seems to be quite sure what the distinction between 4=admin-local, 5=site-local, and 8=organization local really means in practice. In both unicast (1 destination) and multicast (multiple destinations) the big distinction is between node-only (e.g. loopback), link-local (usable with immediate neighbors) and global (usable past routing hops with the general internet). On the unicast side link-local scope addresses have special prefix fe80::/64. Deprecated site-local scope addresses used to have special prefix fec0::/10. Multicast has ff::/16 as its marker, but the next 8 bits are 4 flag bits plus four scope bits, which is why you see a lot of ff02::/64 stuff: multicast, no flags, link-local scope, group ID mostly down in the low bits, e.g. for neighbor discovery.
The tricky point to wrap your head around regarding link-local addresses is how the interaction between the the address, the interface, the link, and the node plays out. The addresses are assigned to interfaces. The addresses are only valid within a particular scope. The scopes at network layer 3 in the OSI reference model (IPv4 or IPv6 in TCP/IP internets) interact with the implementation technologies at layer 2, e.g. over ethernet broadcast (in v4) and multicast (in both v4 and v6) are both layer 2 ethernet concepts and layer 3 IP concepts. These days ethernet scope tends to be synonymous with VLAN broadcast reach, which fuzzes things across multiple switches and ports in network administrator defined ways. What fun!
Back at the fe80::/64 link-local unicast scope addresses. All IPv6 interfaces have these, since you can't find routers or neighbors without them. The node has to have one or more strategies for picking the host parts of these addresses. Strategies include the unlikely case of static assignment, the more typical case of EUI-64 mapping from the 48-bit ethernet address, or the privacy approach of picking most of the bits at random. Let's say we're a typical Linux notebook with 3 hardware network interfaces for ethernet, wifi, and bluetooth. Each one has a 48-bit ethernet style MAC address, which gets prefixed by fe80:: to make a 128-bit interface identifier with link-scope. So "ip address show" will exhibit 4 interfaces, loopback, ethernet, wifi, and bluetooth. They'll all have link/ether scope layer 2 addresses (null for loopback), and at layer 3 maybe some ipv4 "inet" family address, and an inet6 family link-local address. If you have a configured IPv6 global scope address, say on eth0, you'll have at least two inet6 family addresses, the link-local scope one starting with fe80, and the global scope one starting with 2.
Now consider the routing dilemma for trying to ping ff02::2, all routers. It's got multicast scope 2, link-local, so we're going talk to it using a link-scope unicast address. But we've got 3 of those. Which interface should we use? In the IPv6 literature the link-scope destinations have to be further qualified with a "zone identifier" to resolve this dilemma. The official notation is address%zone, but what the zone ID is allowed to be is implementation specific. On windows zones are numeric and show up in the output of "ipconfig /all". On Linux they might be the name of the interface, e.g. %eth0, but not all commands like that sort of thing yet.
The whole scope versus interface versus address family thing may become a bit clearer if you run
ip address show
ip maddress show
ip -4 route show
ip -6 route show